5 ms·

I believe the title is misleading out of context, I think it is meant to lack conclusions or clear statements and simply outline some areas for discussion ... a

I believe the title is misleading out of context, I think it is meant to lack conclusions or clear statements and simply outline some areas for discussion ... a proposition paper? I'm not familiar with what that really means, just jumping to an assumption about the intent of the paper that I think was not made clear in the title as is.

jackfoxy 9y ago
In that case I won't waste my time reading this, but submit my outline of a Useful Theory of Software Engineering: It comes down to making a good choice in each of the following areas. (My choice is in parens, along with my comments.) Cloud Platform (For historical reasons I am on Azure. I have some experience with Google. It does not hurt of course to work in several, but the cognitive overhead of gaining a real in depth devops knowledge on very many platforms will be overwhelming for many people, especially as the vendors invent stuff on the fly.) Relational Database Management System (Strive to learn SQL and 1 or 2 platforms, mine is SQL Server, as best as possible. There is only one useful data model, and it is the relational model. You will store data with other means over your career, but learning them is mostly trivial, and if your are intentionally using a different data model than relational, you should have a good reason. Also learn to data model using natural keys. This is a huge topic unto itself. The main justification is it will simplify the queries you end up using. A friend of mine is working on a book on nat keys. There is a real shortage of good literature on this topic.) An application programming language (Mine is F#. Learn one or 2 languages well, chosen because the compiler and canonical workflows do so much to keep you out of trouble. You will have to know 1 or 2 scripting languages our of necessity. Given the other areas you need real expertise in, I am not a fan of spending a lot of time with the language of the month club. Become an expert in the language(s) you use. It's a career-long pursuit.) Project Management (Recently saw a good overview video of the "no estimates" approach. I was sceptical before I saw it. Not really impressed by Agile, but I don't want to wade into that swamp.) Specification Language (A new area for me. I am interested in TLA+, but I'm still learning it. The idea of a specification language that delivers an unambiguous spec at an arbitrary level of granularity that you can manipulate and refactor is very appealing to my sense of propriety. We spend too much time going straight to prototype in our favorite language, refactoring it, etc. TLA+ forces you to focus on actual spec and not implementation details. The prototype approach leads us all to confuse implementation and spec.)
- nxtrafalgar 9y ago
  This does not describe software engineering, as that term is academically defined.
  - jackfoxy 9y ago
    and that is?
    - nxtrafalgar 9y ago
      The systematic study of methods for producing high quality software. Your comment is equivalent to calling a flexural test machine 'materials engineering'.
      - jackfoxy 9y ago
        Granted. I'll throw out the cloud platform, but keep the others. 1) There is no substitute for the relational model. Clearly it is a paradigm for building mathematical objects. 2) I didn't strongly advocate my choice of F#. Strongly-typed, functional first, ML syntax language is the sweet spot today. In theory this predicts faster development and fewer bugs. All software assemblies are mathematical objects, those built with strongly-typed, functional languages tend to be more humanly comprehendible. 3) No estimates allows practitioners to make useful projections of the course of a project. (Of the 4, this one has the weakest claim to belong to theory, yet I will argue useful projections are a kind of prediction.) 4) TLA+, or something like it, separates spec from implementation detail and makes "predictions" (at arbitrary level of granularity) of what a completed software component will do.
        verall 9y ago
        Lots of systems software has no place for any kind of RDBMS, I'm not really sure I understand what you mean by "no substitute".
        9y ago

jackfoxy 9y ago

In that case I won't waste my time reading this, but submit my outline of a Useful Theory of Software Engineering: It comes down to making a good choice in each of the following areas. (My choice is in parens, along with my comments.) Cloud Platform (For historical reasons I am on Azure. I have some experience with Google. It does not hurt of course to work in several, but the cognitive overhead of gaining a real in depth devops knowledge on very many platforms will be overwhelming for many people, especially as the vendors invent stuff on the fly.) Relational Database Management System (Strive to learn SQL and 1 or 2 platforms, mine is SQL Server, as best as possible. There is only one useful data model, and it is the relational model. You will store data with other means over your career, but learning them is mostly trivial, and if your are intentionally using a different data model than relational, you should have a good reason. Also learn to data model using natural keys. This is a huge topic unto itself. The main justification is it will simplify the queries you end up using. A friend of mine is working on a book on nat keys. There is a real shortage of good literature on this topic.) An application programming language (Mine is F#. Learn one or 2 languages well, chosen because the compiler and canonical workflows do so much to keep you out of trouble. You will have to know 1 or 2 scripting languages our of necessity. Given the other areas you need real expertise in, I am not a fan of spending a lot of time with the language of the month club. Become an expert in the language(s) you use. It's a career-long pursuit.) Project Management (Recently saw a good overview video of the "no estimates" approach. I was sceptical before I saw it. Not really impressed by Agile, but I don't want to wade into that swamp.) Specification Language (A new area for me. I am interested in TLA+, but I'm still learning it. The idea of a specification language that delivers an unambiguous spec at an arbitrary level of granularity that you can manipulate and refactor is very appealing to my sense of propriety. We spend too much time going straight to prototype in our favorite language, refactoring it, etc. TLA+ forces you to focus on actual spec and not implementation details. The prototype approach leads us all to confuse implementation and spec.)

nxtrafalgar 9y ago
This does not describe software engineering, as that term is academically defined.
- jackfoxy 9y ago
  and that is?
  - nxtrafalgar 9y ago
    The systematic study of methods for producing high quality software. Your comment is equivalent to calling a flexural test machine 'materials engineering'.
    - jackfoxy 9y ago
      Granted. I'll throw out the cloud platform, but keep the others. 1) There is no substitute for the relational model. Clearly it is a paradigm for building mathematical objects. 2) I didn't strongly advocate my choice of F#. Strongly-typed, functional first, ML syntax language is the sweet spot today. In theory this predicts faster development and fewer bugs. All software assemblies are mathematical objects, those built with strongly-typed, functional languages tend to be more humanly comprehendible. 3) No estimates allows practitioners to make useful projections of the course of a project. (Of the 4, this one has the weakest claim to belong to theory, yet I will argue useful projections are a kind of prediction.) 4) TLA+, or something like it, separates spec from implementation detail and makes "predictions" (at arbitrary level of granularity) of what a completed software component will do.
      - verall 9y ago
        Lots of systems software has no place for any kind of RDBMS, I'm not really sure I understand what you mean by "no substitute".
        9y ago