Headlines | Linux | Apps | Coding | BSD | Admin | News
Information for Linux System Administration 

Why software sucks


I've heard widely varying opinions on why software is so lousy, the most recent from this article by Charles C. Mann. Mr. Mann makes an excellent anecdotal case for just how bad software has become. Then, he concludes that perhaps a bit more litigation would help matters. While one of the perpetrators of bad software he cites is Microsoft, they, and other wealthy software development companies, might be among the least vulnerable to lawsuits brought over poor software. As is frequently the case, increased litigation would probably put the small developer at even more of a disadvantage relative to the large software corporation.

But more to the point, why is software so bad? Programming is sometimes compared to an engineering specialty and the point is made that product standards are much lower for software. Software, unlike building construction, for example, is pure design. The actual programming phase is just a finer grained version of what we programmers normally call 'design'.

Software development is one hundred percent design.

Consider the implications of that statement for a moment. Virtually all of the cost of software development is, directly and indirectly, the cost of design. If a student architect could design a skyscraper, push a button, and have some futuristic genesis device instantly construct the building at virtually no cost -- and at no danger to anyone -- and with perfect components throughout, would he not do so? Further, imagine that with a push of another button, the entire building could be reduced back to its constituent atoms.

The student could try and try again, refining his design until it was finally just what he wanted. Now, imagine that there was no danger in occupying such a building. Would it change the way we make buildings? Given the alternative of spending millions to build the building the old fashioned way versus spending a fraction of one percent of that to do only the design -- and automate the remainder for virtually nothing -- I suspect that the market would choose the vastly cheaper method.

For software that doesn't involve life-or-death applications, the development cost model closely resembles our fictional architectural scenario.

People are understandably reluctant to add real engineering discipline to software development. While there is no physical building phase, the complexity of a large application is staggering. A large program might have millions of (logically) moving parts, all interrelated. To prove that it all works correctly, as specified, might be more than just prohibitively expensive; it may well be impossible. And even if such verification were possible, proving the correctness of a large program would greatly delay the release date.

Perhaps life support systems, X-ray machines, and other such critical programming does belong in the engineering realm with formal education requirements, legal responsibilities, and state certification. But for my favorite projects, I think the status quo is just fine.

Yes, software sucks -- but it's usually cheap. Further, in my experience, the cheapest software, free, seems to suck the least.

Fast, good, cheap: choose two.
mail this link | score:9011 | -Ray, June 19, 2002 (Updated: April 26, 2011)
More Programming articles...

Buy Large Wall Art on Canvas

coding headlines

No Starch Press has published my Perl One-Liners book!

Detailed Error Handling In Bash

Develop your own Raspberry Pi OS

Unix: Shell Script Wrapper Examples

Using Git for Source Control

Tutorial: Install SVN, Configure multi-protocol access (Ubuntu 11.10)

E-book: Perl One-Liners Explained

bash scripting: Looping through a list

e-book: Sed One-Liners Explained

String matching in regular expressions

Apache2, mod_rewrite tutorial: Redirect requests by device

Bash Functions

Tutorial: Android app build environment with Eclipse, PhoneGap (Ubuntu 11.04)

Debugging Shell Scripts


Firefox sidebar

Site map

Site info

News feed


(to post)


Articles are owned by their authors.   © 2000-2012 Ray Yeargin