126 years and the scope of the problems solved. You give an excellent example of the scoping issue: Someone can write a computer program that will run detailed

126 years and the scope of the problems solved. You give an excellent example of the scoping issue: Someone can write a computer program that will run detailed mathematical models of a bridge and cross-check against established data. I can also write a program to simulate flutter, run simulations of car engines, the power grid, the stock market (You can program almost anything imaginable). I challenge you to write a program that will run a detailed mathematical model of a computer program and cross checks against established data gleaned from other programs. Even if you did, it wouldn't be terribly useful as it would just tell you that the program runs in such and such a way; you'd still not know if it actually does what it is supposed to do. Does it fit the problem domain, or is there some 'flutter' that you didn't know about? A lot of the improvements in reliability of engineering disciplines of the last 50 years have been because of the ability to simulate things better... mostly by use of the computer. There are therefore two types of error in a piece of software: 1. 'Stupid' error (I used the wrong units or I used the wrong function). 2. Thought error (I didn't understand the problem or I goofed in my reasoning about it). I'd argue, therefore, that the 'stupid' errors are the errors that can be solved by software engineering. (Using higher level languages, better compilers, better type systems, etc.) The issue being that there is only so much that you can actually do to solve them with software. The second set is a bit more difficult. Am I going to validate my bridge simulator by using a different bridge simulator? Sometimes we certainly do do this, and this is kind of the basis of iterative development (if each version of a program is a different program). At some point, I will need to understand Civil Engineering as well as Software Development to get my program to function as a Civil engineer would expect it to. This would imply, that at least in some domains, software engineering is the equivalent of meta-engineering. (I am programming the set of rules used by civil engineers). It gets more difficult the further away from engineering/scientific disciplines you get. What exactly would be the discipline be behind web programming or writing an HTTP server? Where can I get my thought guidelines to understand how I should think about the different problems? I'm sure that there is progress to be made in software engineering, but I'd guess the progress won't come from looking at engineering disciplines, and I'm pretty sure it is wrong to say that the only difference is timeframe.