Producing software is a process. Applications do not just happen, programs do not simply spring full-blown from the brains of programmers. This is a good thing, since one of the basic principles of the modern “quality” movement is that processes can be improved. Indeed, the goal in the so-called “total quality” movement and its various incarnations in the software world is not just improvements in steps or fits or bursts, but continuous process improvement. The most advanced organizations not only study the processes by which software and applications are produced, but have instituted programs for feeding their findings back into the process in a closed loop that refines their systems and procedures continuously.

Achieving this somewhat utopian ideal of nonstop improvement can take a major corporate commitment. Companies that embark on this journey toward software engineering enlightenment often start with an expensive and elaborate appraisal of their current culture and practices. They may hire consultants to evaluate their organization using something like the Capability Maturity Model developed by the Software Engineering Institute, an elaborate rating that boils down to a number from 1 to 5. If all you want to do is find out how mature your organization is, you can save your money. Probably you are at Level 1, meaning your processes are lousy and unreliable but you don't even know quite how lousy or unreliable because you don't measure anything. Almost everyone is at Level 1, so this is a fairly safe bet. (If you want, I'll come visit and send you a bill before announcing the foregone conclusion.)

The real reason for going through the pain and expense of a more elaborate and formal assessment is not to find out a number but to learn in some detail where and how things are going wrong and where you can start creating institutionalized practices that will make things better. Maybe after some years of effort—and more money to consultants—you will reach Level 3. Rumors of a rare Level 5 software engineering group being spotted in the wilds of rural Virginia are frequently referenced but remain unconfirmed. Do not misinterpret my casual stance. I am not knocking consultants—I am one myself, after all—nor am I questioning the potential payoffs of thorough organizational assessments; in fact, my firm does such assessments for clients. And I am most emphatically not opposed to software developers being prepared to invest substantial sums and resources in process improvement. But I do want to make clear that I think there may be other ways to create improved processes, ways that are not as dramatic, do not cost as much, and are not quite so high profile.

This section will look at some of these simple ideas and modest proposals for improving software quality through better development processes. There are no major social programs here, nothing that could justify astronomical consulting fees for business process re-engineering, just things that small groups and even individual developers and managers can do to do a better job.