A year or two ago, a combination of curiosity and vanity prompted me to set up a Google Alert search that pings me every time the name “Yourdon” pops up on the Internet. I’ve been intrigued to see how many distant Yourdon relatives are getting written up in local newspapers in Kansas, North Carolina, upstate New York, and other remote corners of the country; and I’ve also been intrigued to see references in today’s au courant computer publications about things that I can barely remember having done back in the 1970s.

For example, an Infoworld “Gripe Line Weblog” posting appeared yesterday,with the intriguing title of “The Source of Bad Software.” I’m sorry to say that I don’t subscribe to this blog (though I’ll do so starting today), so I would have missed it completely if it hadn’t been for the Google Alert. It turns out that the author, Ed Foster, offered his own perspective on why we still suffer from the existence of mediocre software, during which he exclaimed, “The basics of good coding practices have been known since Ed Yourdon wrote about functional decomposition in the 70s. Give me a break! ”

Well, I wasn’t the only one, and not even the first one, to write about functional decomposition; I was the co-author, with Larry Constantine, of a 1975 book entitled Structured Design that went into more detail about functional decomposition than most people ever wanted to know. But before that book, Larry had co-authored a 1974 IBM Systems Journal article on the same topic with Glen Myers and the late Wayne Stevens.

Anyway, I don’t think it’s a lack of knowledge about functional decomposition that explains the situation that Mr. Foster is complaining about; and it’s not the answer to his rhetorical question of, “Why do managers and programmers put up with disgusting code like this?”

There is, I’m afraid, a much simpler answer, even though it’s repugnant to all of us who respect and enjoy good, clean, well-designed, well-tested, robust software; it’s the principle of good enough software. Foster was complaining about yet another security vulnerability in Microsoft Windows in his blog posting, but there are certainly many other examples of software that’s not perfect, not excellent, not even really “good” … but nevertheless “good enough” for the marketplace that’s using it.

If you haven’t heard of this concept before, you may well have a strong negative reaction to it. I first started writing about good-enough software about 10 years ago, and I posted a blog entry about it a couple months ago; you can even find a Wikipedia article on the “principle of good enough.” Bottom line: mediocre software survives because society tolerates it, and believes (rightly or wrongly) that it really is good enough.

One aspect of the good-enough phenomenon that I didn’t think about very much 10 years ago is inertia: even if you know your software is mediocre, it’s often too much of a nuisance, too expense, and too time-consuming to seriously consider abandoning it and switching to a better alternative. Most large companies have far too much of a financial and human investment in Microsoft software and the ERP suite that runs their day-to-day business operations to seriously consider switching, even if a rational analysis conclusively proved that Linux, or Mac, or whatever, was cheaper, faster, and more secure.

Indeed, the situation may be even more insidious: if a company did abandon its Microsoft software en masse and (for the sake of argument) switch to open-source software like OpenOffice, what would all those Microsoft-certified software geeks do for a living? I’m not trying to pick on Microsoft here; you could make the same argument about Oracle and SAP and a long list of other products and technologies that people have used as the basis for an entire career. Just like the doctors who seem to make more money by helping their patients cure a disease rather than preventing it in the first place, there are a lot of programmers whose economic value in the marketplace is derived from being able to tweak, configure, debug, maintain, and patch software that should have been eliminated by software that didn’t require all that work.

But while it’s easy to become gloomy about all of this, we need to remind ourselves that there are some really good things going on in the software world. When my colleagues and I were yammering about functional decomposition 30+ years ago, we didn’t have Web browsers; heck, we didn’t even have Visicalc at that point! We didn’t have Google, which is awesome enough by itself, and we certainly didn’t have anything as wonderfully awesome as Google Maps.

And while the current generation may not have paid as much attention to all the basic software engineering principles as we would like, at least some of it sank in. The whole idea of API’s that facilitate mashups like — well, all of the things on this list and this list of mashup blogs, in addition to wacky Google Maps mashups like Earth Sandwich and MapSexOffenders.com — is a tribute to basic concepts of modularized software and clean interfaces. The fact that so many software vendors have not exposed their APIs, in order to enable mashups with other software products they haven’t even thought about but that their customers love, is less likely to be a technical issue than a corporate/business strategy.
All of which means we’ll probably still be complaining about relatively mediocre software 30 years from now. Hopefully we’ll also have a new generation of something as fundamentally useful for day-to-day work as spreadsheets and Web browsers, and hopefully we’ll have some new things that will dazzle us the way Google did a few years ago. But as for the rest of the billions and billions of lines of code that the next generation will be churning out … well, the most realistic forecast, I think, is that it will be barely good enough.