Programming Analytics

A feed of interesting tidbits from IT, software engineering, business intelligence, and videogaming.

I saw this article today which compares programming to building a house. It’s a noble sentiment.

However, one of the advantages of having (I can hardly believe it) 22 years of professional software development expertise is that I have seen trends like this come and go. Every few years, this theme of “Programming should be engineering!” resurfaces. And afterwards, even though some progress was made, all goes back to the way it was before, and the companies that do “release-early, release-often” win out over the companies that do rigorous design.

Why is this?

Programming is, unfortunately to say, not like engineering in the way we wish it was.

When you are designing a house, or designing a bridge, or any other gigantic physical work, you have complete knowledge of your materials available. If you say that you wish this roof to be held up by two steel beams or by a wooden frame, you can look up the quality of the materials and know exactly how it works.

When you are doing mechanical engineering, physically changing something has a known time and cost and often is impossible once a system is built. In software engineering, changing a component is virtually costless.

In programming, every detail is just as unique as the overall design of the application itself. Every detail can suffer from the same problems that can cause the program as a whole to fail.

I think it is much more fair to compare software to law. A programmer is like a lawyer. They have rules to follow and a flexible set of limits to push against. But at every step of the way, the rules and the limits are subject to interpretation. At every step of the way, the results of something you thought you understood can surprise you.