Follow Up to "Most Software Stinks!"

Recently, I wrote an article titled Most Software Stinks!. In the many interesting replies I received to the article, two general comments recurred often. One of the comments missed a major point of the article, but the other showed an insight I had overlooked.

The first recurring comment was that software development is simply more difficult than other kinds of engineering and, therefore, cannot be judged by the same standards. In this view, creating software is harder than creating any kind of physical structure, so we cannot expect software to have the same high quality as many bridges and office buildings. (Closely related is the assertion that we cannot expect software to be completed on time and on budget, as physical construction often is.) In my opinion, such an assertion highlights the worst qualities of software developers.

We think we operate on a higher plane of activity than our mechanical and structural engineering brethren. We think the sorry state of software engineering -- cancelled projects, lousy quality, missed budgets -- is because we do something that is harder than other engineers. The fault, we believe, is not with us, so there is little we can do to improve the performance of software development teams. This is a convenient point of view, if we can sell it. Unfortunately, it is baloney.

A close look at complex projects tackled by other engineering disciplines shows these undertakings are every bit as difficult as software development problems. An excellent example is found in the PBS documentary about the 1990 building of the Clark Bridge over the Mississippi River. Watching the constraints and challenges faced by the designers and construction crew is just like viewing a documentary about a large software development project. The bridge had it all -- new engineering techniques, time and budget constraints, unexpected disasters -- just like the hurdles faced by a team of programmers trying to beat a competitor to market. Any software developer who thinks our field has special problems should watch this film.

The second recurring comment concerned my discussion about readability of software source code. In the article I stated, "Readability is the one area of software aesthetics that does not have an obvious parallel with physical construction." I went on to explain that source code readability nonetheless is important and stated why this is so. That section of the article bothered me when I wrote it, because it did not fit with my overall analogy between software development and physical construction. Many readers kindly jumped in to defend my original analogy.

The most commonly cited example was construction blueprints. Readers pointed out that a well-built building still requires blueprints to reveal its internal structure, just as well-designed software still needs clarifying comments. If we want to modify a building, the blueprints help us find the right places to cut and nail, just as source code comments help us with debugging. Another example from readers was color-coded wires and circuit breaker labels. A perfectly made electrical system in a house is still confusing (and possibly dangerous) without consistent use of the black/white wiring distinction. An electrical panel is impossible to understand without labels stating which circuit breaker is for the second-floor bathroom and which is for the garage. These ideas apply to software also. A great object-oriented design is made better by comments that help the next programmer understand it.

My thanks to everyone who wrote to me about the article, whether you agreed with me or not. Writing would not be half as much fun without feedback from readers.

About the Author