Does Construction metaphor harm Software Development?

For some time already I was thinking to myself, that construction metaphor, applied to software development field so frequently, doesn’t serve its best purpose. We design and build our software, and we even have Architects in our projects. You can often hear people referring to construction experience, saying “You wouldn’t start building your house from the roof, wouldn’t you?” or “How would you build a house without an architect?”

It seems to make a good sense to refer to Google, before writing your first blog post. Not at all surprising that my dumbest web search quickly ended up in me reading an article, criticizing the famous “Code Complete” book by Steve McConnell for exact same reason: Software Development isn’t like Construction.

To me the cornerstone difference is the building process. In construction, building means, roughly speaking, putting bricks together. Well, also digging the basement and assembling concrete panels together, but all that doesn’t really matter. What matters is, that this process takes a considerable amount of time and effort. And, having a wild assumption that the engineers did not screw up the blueprints, the building process is supposed to happen only once. That is when your house is actually complete -- when you have built it!

Now, what’s the analogy for this process in software development? I wouldn’t say that it is the actual coding. Because this is more similar to what construction engineers do -- design blueprints, according to which the physical thing is built. As I see it, the building process in construction corresponds to compilation and deployment processes in software development. That’s the thing your build script usually does, isn’t it? :) Your code together with the build scripts are your specs and blueprints, which make the actual building happen.

But there is one significant difference between building a house and building your software project. Compilation and deployment do not take as much time, as putting the bricks together on a construction site. It is very much automated and doesn’t take as much effort at all. And it’s repeatable. Building your software is so easy compared to construction, that you even do it frequently. Frankly, it’s the fastest way to verify, what exactly you just did. And hey, most likely your software is not complete after the build process.

In fact, I don’t even know when that point is exactly. When is your software complete? There’s always room for adding configurable and resizable windows to your software walls, and all kinds of other stuff. The smells you get from applying the construction metaphor to software development are something like:

• the famous “If it works, don’t touch it!” engineering principle;
• the widely used Feature Freeze concept.

Software Development is not like Construction. You deal with abstractions, not concrete blocks. You change your thinking and even the idea of the entire project during the time it’s being developed. The thing you actually build is Knowledge. Let’s just not drag thousands of years of construction experience into the software industry. Wild idea -- maybe it should happen vice-versa even? :)

.