Edsger Dijkstra famously argued that software should be finished in version 1.0. "You just cobble something together to sell. It need not be any good. As long as you fool people into buying it, you can always try to make better versions later. So you get these version numbers, even with decimals, versions 2.6 or 2.7. That nonsense. While version 1 should have been the finished product."
Dijkstra, bless his soul, was an ivory-tower academic idealist. He thought that software could be proven correct mathematically, and he worked long and hard to that end ... without even a version 1.0 to show for it.
Nevertheless, he had a point.
Over 40 years or so in the business I've spent time developing software for internal use in government, insurance, banking and others. I worked for 6 years at a company that sold, among other things, APL software, and software for logistics and materials management -- except for the APL, vertical markets all, high-priced, low-volume applications for big business.
Some of those 40 years, including these, my later years, I've been the customer rather than the vendor -- the victim, shall we say, rather than the perpetrator. I've seen very few perfect "version 1's". A few, but very few. (One, by the way, Titanium Schedule, for college and university counseling centers, is still actively developed and used, is nearly the best of its type that I have had the pleasure to deal with. SAS runs a close second, in another type of market.)
Not only are many of these packages not perfect in version 1.0: even in version 9.6.0.13 they come equipped with a readme that contains a long list of unresolved items, problems the vendor already knows about but hasn't yet fixed. What's wrong with this picture?
EWD didn't have to deal much with the real world, where we don't expect perfection out of (or in) the box. For a software company to survive, it has to sell something. Google can give away software (which thus does not have to be perfect, viz. the fact that most of it is perpetually labeled "beta") because it sells advertising. Version 1.0 (or, these days, often, version 0.something) usually derives from an idea that hasn't yet seen users and their depredations. Unless it's sold, there may never be a version 2.0, perfect or otherwise.
So we accept that we must wait for the next upgrade to fix many of the bugs we find in the current version; at a minimum we must pester the vendor for patches for the most egregious problems. And then we must warn the users that this next version that they clamor for will have new features, but will also trade in the old set of bugs for new ones.
And indeed, most new versions focus on the nifty new gizmos that have been added to the software. The vendor says s/he is responding to customer demands for new features. So what if existing customers don't need that new ajax-enabled form. Vendors are actually responding to the demands of prospects. After all, "customers" have already paid the buy-in price and maintain the vendor's revenue stream with annual maintenance fees (note that "maintenance" works both ways). If the software needs that spiffy new feature to close a quarter-million-dollar deal, then all of us paying customers get that, too.
For the same reason, my proposal will never happen.
I propose that software vendors periodically take a year off new-product/new-feature development, say, every 6-7 years. Take a year to fix all the known bugs, improve performance, smooth out production features, interfaces, all the little details that so annoy those of us who try to keep these monsters running month to month, year after year. Make the installers more streamlined, more flexible. How much happier customers will be, more willing to provide good references, if they can expect the software to work as advertised. Too many of these types of packages expect to be the only application on a machine, and to be installed on the C: drive. Take a year to talk to existing customers and incorporate those little suggestions that will make a real improvement for everyone.
I graze a lot of blogs about software development, many of them about startups, how to hire the best coders, which languages or platforms to use or support. And I know that developers usually prefer to "develop" new code, new applications. When we hire, shouldn't we also try to find those who insist on quality, and who demand the time to "do it right?" Can we find programmers who like maintenance (even if they don't really prefer it). I've always found it challenging to figure out what the programmer before me was thinking when he coded that spinlock and gave it the name of a Dutch pastry.
For most of us, a Dijkstra on the staff would be a luxury. I've worked with a few perfectionists, and I'll take someone a little less lofty every time. Computer scientists have a place at Google and Microsoft, at Oracle and a few other places. What most vendors need, however, are good programmers.
John Cook, in a slightly different context, speaks about the myth of progress: "Companies profiit from the myth of progress by selling new versions." Maybe we can come closer to Dijkstra's nirvana -- dispel the myth -- if we allow software to lie fallow once in a while, sprinkling it liberally with manure and tilling its rich soil.
Atom