In my opinion, software, if it is a form of engineering, is a very strange form. A mistake in one part of the code can potentially affect any other part of the

In my opinion, software, if it is a form of engineering, is a very strange form. A mistake in one part of the code can potentially affect any other part of the code. Not only that, but the effect it has is practically unbounded. If we were making a car, then it's a bit like putting in a cup holder causing the fuel tank to explode. We can't efficiently reason about our designs because we can't efficiently build from reusable parts that are known to work. Sure that cup holder works in every body else's car, but it makes our fuel tank explode. There is no equivalent to things like "tensile strength" that we can calculate to say, "This will be good enough for this project, but for a different project we should use something else". We just shut our eyes and pick our components based on what the most annoying person in our team wants to use. Many organisations make the mistake of thinking of software development as if it were like building a bridge. We think that we can choose a framework and it will reduce the amount of thinking that we have to do. Then half way through the project we are madly trying to hire Rails experts because nothing works right and it has something to do with the internals of Rails (which we were trying to avoid understanding). Putting aside the gargantuan task of gathering requirements for a second, building software sometimes has the feel of building something physical. Because software is seen as a thing that people utilise, they think that we will eventually use the same techniques that we use for building physical object/systems. The reality is that software does not follow laws in the same way that a bridge or a car must follow physical laws. You make up your own laws in software and the only thing that is important is internal consistency. It's a bit like creating a universe for your bridge to live in. The success of your bridge depends on whether or not you chose sane rules that other people could understand. If we were to think of it as engineering, we would need "engineers" who studied every software system so that they could understand the "laws of physics" (which explains why Rails developers get paid so much!). BTW, I'm picking on Rails for no good reason. You can insert whatever framework/library/language/system you currently hate because it really doesn't matter all that much. Each one encapsulates it's own universe and requires us to study it to understand how it works. Our ability to extrapolate from one system to another is dependent upon whether or not the developers actually chose to imitate each other or not. On the other hand, we have some advantages over engineering. Our universe is made up. If we choose we can limit the rules to only things that we understand very well. We also get to see the source code (unless you work with proprietary systems, in which case you have my undying pity). We don't have to discover the laws of physics by experimentation (hmm... it doesn't stop some programmers, though...). The laws might change from day to day, but we can even write so-called "tests" to alert us when some idiot has inadvertently changed the gravitational constant and caused the universe to implode. Personally, I think the differences between programming and engineering are big enough that we lose a lot by hoping that it will become engineering. For some reason there seems to be a desire to call programmers "engineers". I hope this trend reverses and we embrace a new discipline that is more suited for our needs.