> There are kinds of making other than engineering. True enough. But the piece argues (I am the author) that software engineering is not making, it's designing

> There are kinds of making other than engineering. True enough. But the piece argues (I am the author) that software engineering is not making, it's designing. > Carpentry is not engineering. Cooking is not engineering. Carpentry is a craft, but furniture design can be engineering. Cooking dinner is a craft, but designing the menu and production process for a chain restaurant is definitely engineering. > Before you can declare that making software is (or can be) engineering, you have to be able to explain why those things aren't. My position is that they are (or can be), when analysed in an analogous way. You've asserted that they self-evidently are not, even in the absence of a rationale for why. I simply don't agree. > My tentative theory is that engineering has rigorous ways to check whether a design will work before it is manufactured I appreciate you sharing your theory! However, I believe you'll find the history of engineering has largely been one of people doing stuff first and then later finding ways to reduce the cost by doing analysis. I highly recommend watching one of Glenn Vanderburg's "Real Software Engineering" talks for a more in-depth treatment of that subject: http://vanderburg.org/speaking/ http://vanderburg.org/speaking/ > A mechanical engineer might need to draw a detailed design, but can then check it rigorously with finite element methods. That's great, but finite element analysis won't tell you e.g. where water might pool causing a structure to deteriorate, or that a machine can't be properly maintained because a part is too difficult to access. If you worked in any of these fields I think you'd quite quickly be disabused of the notion that they consist of just plugging designs into known formulae until the computer accepts one. Similarly, we have plenty of similar tools in software (e.g. Big-O analysis), but we don't kid ourselves that using them is the be all and end all of developing software. > When we make software, in practice, we have to construct the software and test the artefact, hoping that our tests are adequate. We do that in practice because it's more efficient. I can't accept a definition of engineering that holds that we could claim to be doing engineering only if we did things inefficiently, because it's self-contradictory. That's the opposite of engineering.