Why Programmers are NOT Engineers (and that's a good thing)
===========================================================<p>1. Engineers design and build the same types of things over and over again, from principles that have been developed, tested and put into practice over, literally, thousands of years. These principles are rarely expanded upon, and only after careful testing and proven performance. Programmers on the other hand consider building the same thing over and over again to fall in one of three categories (1) stupidity (2) ignorance or (3) market failure.<p>2. If an engineer builds two bridges of exactly the same specification, the cost of building the second bridge will be reasonably close to the cost of building the first one (technological advances and inflation not withstanding). If a programmer writes a useful program, and wants to share it with his friends and family, the cost of each additional copy of the program is fairly close to zero. Unlike the engineer building a second or third bridge, there is no need or reason for the programmer to create another copy of the software by designing, writing the code and compiling a second or third time.<p>3. Following on from (1) and (2) above, an engineer designs blueprints that describe _exactly_ how the structure is to be built, but a programmer usually has no idea how the program is to be built, because if s/he did know, then it means someone has built this before, and therefore there is no reason to build it again, because the marginal cost of copying a previous design is zero. This tends to make the best programmers experimentalists (because the risk is small) and plagiarists (because the cost of copying existing designs is zero), and the worst programmers are those that think like engineers. Conversely, experimentation in engineering is discouraged, especially on things like bridges, because it is costly and dangerous.<p>4. But what about the domain known as computer security? Shouldn't security be 'engineered'? Yeah, good luck with that. People who crack computer security are nimble experimentalists. Because the cost of experimentation is so low, security cracking tends to be a never ending series of probes until a weakness is found. Protecting against that approach cannot be 'engineered', because the engineering process is one in which you plan for every known contingency. But if you knew every possible contingency, there would be no security issues, because they would all be covered off.<p>Sorry, the above is a bit rough. I'm still refining my ideas on the topic. Feedback welcomed.