Every now and then the topic of software engineering compared to other kinds of engineering pops up. It’s almost always either in the context of bad estimates on the time it takes to finish a software project or in the context of unusually high failure ratio of software projects compared to other kinds of engineering projects.

A good recent take on this topic can be found at Jeff Atwood’s popular Coding Horror blog in a post It’s Never Been Built Before. In short, Jeff claims that the reason software projects fail and are difficult to estimate is because they are totally unlike the other kinds of engineering projects. His analogy is actually quite good, so I’ll just quote him:

One kitchen remodelling project is much like another, and the next airplane you build will be nearly identical to the last five airplanes you built. Sure, there are some variables, some tweaks to the process over time, but it's a glorified factory assembly line. In software development, if you're repeating the same project over and over, you won't have a job for very long. At least not on this continent. If all you need is a stock airplane, you buy one. We're paid to build high-risk, experimental airplanes.

I think this is precisely what's going on. But does it have to be like that?

Funny that the term factory assembly line has been mentioned because that’s precisely what some new software development techniques have been named (and I think it’s an unfortunate name) – software factories.

There are many definitions of software factories. My interpretation is that this is a way to formalize software development on a somewhat higher level of abstraction so that we can build software more easily and reliably and end up with a “less-experimental airplane”.

Differently put, some people (me included) think that software development does not have to be highly experimental. While it’s not as repetitive as building a train wagon over and over again, it’s not as experimental as a new stealth fighter plane, but something in between¹. The reasons we, developers, build a highly risky products are many, some completely out of our hands, but we can do something to improve the process.

The progress in the field of DSLs (Domain Specific Language) gives me the most hope. Expressing your customer’s intentions in a language specifically designed to address the needs of the problem domain tends to be much more readable than a bunch of Java, C# or Python code.

¹An example of a technology that moves us in the right direction is Windows Workflow Foundation.