Write Yourself a Minivan

One of my favorite "Dilbert" comics has the pointy-haired boss instituting a policy of paying $10 per bug that a developer finds and fixes. In the wake of the boss’s new program, we see Wally, an ethically challenged programmer, scurry off to "write himself a minivan." Another classic introduces us to Irv, who wrote the company’s accounting system. Irv no longer has to do any real work because he has created what Dilbert calls "the Holy Grail of technology": a million lines of undocumented spaghetti logic. As scary as it seems, these gems from Scott Adams’ comic were likely mined directly from any number of successful corporations. As IT professionals, we have to wonder when the backlash of developing more and more complex software will finally hit.

Some critics are predicting that NT 5.0, now known as Windows 2000 will be the most spectacular failure in software history. Microsoft’s Steve Ballmer even recently agreed that nobody enjoys releasing 40 million lines of code. Forty million lines of code! Windows 2000 weighs in at more than five times the size of its Unix competitors. The original release of Windows NT had only 4 million lines of code, meaning the code base has increased 10-fold in just six years. If Microsoft has a fairly typical bug rate of 15 bugs per 1,000 lines of code, we’ll soon be beset with over half a million bugs.

But software complexity doesn’t end with Windows NT. Unix systems have avoided code bloat to a large degree by avoiding building GUI interfaces for most functions. Often, the GUI code used to present a service requires substantially more code than providing the service itself. GUI code creates thousands of new and hard-to-determine code paths through a program, often with timing and sequence dependencies.

We developers write the code that makes these complex systems run. We often choose the language of implementation. We choose how robust the code we write will be. We choose how to handle errors. And, for the most part, management is content to defer these choices to us.

Now consider a different model: the construction industry.

Contractors are licensed by the state to perform functions in which they’ve proven their competency. A book of universal code describes, in detail, the parameters within their work must fall to be considered acceptable. And at every milestone in the construction process, the city will send in an inspector to ensure that the code was applied correctly. Consequently, our homes are built to last for generations. Servicing and remodeling a house is relatively straightforward because a contractor can usually predict what methods the previous builder used.

The construction industry achieves at least baseline-quality work in all of its output because both its members and the state put a high priority on doing so. If builders constructed buildings the way programmers wrote programs, then the first woodpecker that came along would destroy civilization.

Leaving the key decisions about application development solely in the hands of developers and the marketplace is a bit like having the fox guard the hen house. On the surface, neither programmers nor vendors benefit immediately by writing bug-free and easy-to-maintain software. For programmers, since 80 percent of the cost of software is in maintenance, writing maintenance-free software would reduce to one-fifth the demand for their services. For vendors, writing a software package that is free of bugs may reduce the field’s desire to upgrade the package, thereby ending a revenue stream.

But for programmers there is an even costlier price to pay for buggy, hard-to-maintain code: the end of interesting work. The Y2K bug has generated more work for programmers than any technological innovation other than the Internet. Fixing Y2K bugs, however, is not the type of challenge that drew many of us to programming in the first place. While Y2K is sucking research and investment dollars out of cutting-edge projects and into patching up legacy systems, it may only be the beginning of a future filled with boring computer work, where debugging and maintenance outstrips new development by even greater margins. That’s assuming that IS still has investment at all once the bean counters subtract the expense of Y2K off of all the computer-related ROI calculations.

As Windows developers, we can’t simply be content to use the development tools dumped on us by Microsoft if they don’t result in the best code practices. We must be vigilant, willing to support other companies whose development tools result in better productivity and lower maintenance. By doing so we also ensure that Microsoft will continue to improve its own products. Otherwise, we may be writing ourselves a minivan today, but we will be ensuring only monotony in the future. --Eric Binary Anderson is a development manager at PeopleSoft's PeopleTools division (Pleasanton, Calif.) and has his own consulting business, Binary Solutions. Contact him at ebinary@yahoo.com.