Lucid Code: Taming Software Development Chaos

By Jeff Gainer

Despite all the impressive advances in software engineering since WWII, the sad fact is, as an industry, we still aren’t very good at it. We don’t manage requirements well, we don’t test well, we don’t manage quality well or at all, and our products are almost inevitably late. The statistics are staggering; some positively horrifying: the average client-server project is 189 percent over budget, 31 percent of projects are cancelled before completion, the process at 75 percent of software development organizations can best be described as "chaotic." Software quality is frequently a casualty of the marketplace: it is often more cost-effective to bring a buggy product to market early than to bring a relatively bug-free product to market late. And as of this writing, in the spring of 1998, repairs on the Year 2000 software problem are already falling dangerously behind schedule.

Before the innovations of Louis Pasteur, surgery was undeniably a messy proposition. A surgeon would take this inevitable messiness into account, not bothering to change his clothes, wash his hands or instruments between amputations. One would no more do so than today one would scrub hands and exchange starched white sterile clothing between say, cleaning the garage and changing the oil in the car. The suggestion of clean conditions and sterile instruments to perform something so messy as surgery seemed ludicrous.

Similarly, the suggestion of applying standard engineering principals and commonsense management processes to developing software seems equally ludicrous to many today. To be fair, though, computer science and software engineering are young sciences. They are still evolving. Yet with these immature sciences and our jejune efforts, we still manage to produce some amazing things. We are learning not just from our mistakes; we are learning from our successes.

We’ve developed waterfalls, spirals, clean-rooms, best practices and worst practices, Brooks’ Law, good-enough software, peopleware, the Capability Maturity Model, ISO 9001, SPINs, SPICE and SCRUM, as well as countless other development, design, analysis, process improvement and management approaches, aphorisms, methodologies, philosophies and silver bullets. But no matter what the various approaches are, and despite the fact that nearly three-fourths of software organizations are still chaotic, we’ve learned and proven that disciplined methods can and do produce tangible, measurable improvement. True maturity in our industry, however, will take more time. The accelerating pace of development and increasing capabilities of our industry have not reached a point of alignment, and as yet, there is no such point in sight.

Industry maturity, however, is not the concern of this book. Our concern here is identifying the specific problems in your organization, and providing you with specific methods of improving your processes and your products. It is not necessary to employ a "name-brand" methodology or to subscribe to the theories of the management guru of the month. It is better to employ any adaptable methodology than no methodology at all. With the death march paradigm now the norm for development projects, it is more important than ever for IT organizations to adopt an appropriate, highly adaptable discipline for creating their products.

Why do so many organizations remain chaotic? I have observed numerous software development organizations with managers who are interested in quality improvement, but never seem to be able to make the commitment to seriously pursue it. I have concluded that their reasons for not pursuing their quality improvement plans can generally be classified into three categories:

• They don’t know how to do otherwise.
• There isn’t time.
• They like chaos.

Traditionally, software development rewards and promotes those who exhibit exemplary technical excellence. But technical skills and managerial skills are dramatically different, even incompatible. As Lawrence Peter observed in The Peter Principal, managers have traditionally been drawn from the technical ranks, promoted to management on the basis of their technical skills, and thus found themselves at their "level of incompetence." Little, if any, formal training is invested in the managerial skill set required, other than informal mentoring in what Rob Thomsett refers to as "The Body of Bad Knowledge." ¹

In his 1997 book Death March, Edward Yourdon identified a disturbing new trend in software development: the trend toward compressed schedules, compressed budgets and demands for increased functionality, with a risk of project failure greater than 50%. In Death March, Ed comes to the gloomy conclusion that death marches have now become the norm.

More and more often, the client determines the delivery date for a system, often before the specifications have been determined. Thus in many organizations, the use of a RAD (Rapid Application Development) approach quickly turned into FAD (Frantic Application Development). This happens because there simply isn’t time to do things right. Or perhaps there is time, but the death march phenomenon makes for a convenient excuse.

An American icon, the cowboy, the Marlboro man rides the open plains alone, self-reliant, and doing things his own way. This spirit of independence has carried over into software engineering, particularly in the United States. Arrogance, chaos, caffeine, and testosterone fuel the cowboy process model.

Unfortunately, this spirit of independence has been accused of resulting in bloated applications and buggy software. It is possible, however, to harness, as it were, the positive aspects of the cowboy phenomenon, e.g., fostering creativity and minimizing its negative effects, while not alienating cowboys within an organization.

But let's be honest here: chaos is exciting. There is an undeniable benefit from an aura of excitement, a synergy that results from a sense of urgency and being part of a team striving toward a common goal. But this is the crux of the problem with a cowboy culture: while a cowboy coder is an individualist, synergy comes, by definition, only from a team. And cowboys don't make good team players, except in the chance instances when the team seems to spontaneously "jell."

Quality assurance is often confused with quality control. Quality control is concerned with the end result: the product. Quality assurance is concerned with the process used to create the product. Specifically, quality assurance focuses on identifying and implementing processes to-

• Improve productivity
• Reduce defects
• Improve the development process
• Make better products

Quality control is concerned with the end of the development process: the product itself. Quality control addresses the quantifiable questions, such as -

• Does the finished product meet requirements?
• Does the product pass usability tests?

Unfortunately, even those of us who specialize in software quality use the terms interchangeably. Hereafter in this work, though, I will use the term "quality assurance" to refer to the process, and "quality control" to refer to the other end of the process, i.e., testing.

Okay, so you want to produce better quality software, manage schedules and budget better, and get control of your projects--in other words, you want and end to chaos. Obviously, change is essential, but what has to be changed? First, you must admit that no one is going to change the organization for you. You, personally, must effect organizational change, enlist others to the effort.

Sounds easy, right? The sobering reality is that you will encounter varying degrees of resistance from several fronts. Before you attempt to institute any changes, you must identify possible obstacles and develop a plan for dealing with these obstacles.

Don't be surprised if you find the primary obstacles to be people. People are a particularly knotty problem for technical managers, since many technical people are technicians precisely because they don't want to deal with people. Machines are easy. They (usually) do what they are told. Ideas are even easier. But the truly interesting problems are people problems. In the development community, I have worked with a number of memorable people: the rookie developers who believe they can do anything, the veteran developers who realize the limitations of their knowledge and their craft, the leaders who inspire us to do more than we believe we can.

And then there are the customers: they demand from us, frustrate us, inspire us. There is the customer who wants something he can’t specify, but claims he’ll know it when he sees it, the marketing representative who makes unbelievably naive promises, and the customer who knows what she wants and wants to know why it isn’t ready yet.

Start your journey with some baby steps--steps that will be acceptable to everyone. The "best practices" approach is politically very easy, since it is so eminently democratic. Process improvement is typically associated with "top-down" management methods (such as standards, procedures, and methodologies), which are handed down from management to front-line developers.

A different, "bottom-up" approach to process improvement is to identify the "best practices" in an organization and promote their use, while simultaneously identifying counterproductive practices and removing them. The concept of best practices encourages learning from within an organization, by documenting and promoting the practices that work well, thus preserving and passing on key knowledge.

The concept of best practices was developed by the Airlie Council, a task force of influential industry thinkers appointed by the US Department of Defense’s Software Program Manager’s Network. The Airlie Council has identified and recommended over 170 "best practices" for software development organizations connected to the US military. The nine "Principal Best Practices" are recommended to nearly all DOD software projects. But while the concept of best practices has gained acceptance in the government sector, many private sector firms are ignorant of the concept.

The best practices approach is a highly informal method of process improvement, and it is particularly well suited to smaller development organizations. If you want to adopt the philosophy of best practices in your organization, how and where do you begin?

Unfortunately, you can’t buy a set of best practices off the shelf. A caveat: remember that what works in somebody else’s environment won’t necessarily work in yours. If you’re looking for a starting point for ideas for best practices, you can consult the Software Program Manager’s Web site and other sources for ideas, but by its very nature, implementing any best practices program is a unique effort. Identifying best practices is first a process of listening and observing. And after every project, no matter how minor, you and your staff--not just management, but the entire staff--should pause to perform an informal "post-mortem" to identify processes or practices which worked well--and perhaps more importantly, to identify what didn’t work well. Be sure to ask not only what you would do again, but also what you would never do again. This way, you’ll learn from both your successes and your failures.

How do you promote best practices? Identifying what works in your organization is only part of the effort. Next you’ll need to actively promote the use of your best practices. You can publish them on an intranet, distribute hard-copy newsletters, or exchange ideas in regular meetings. The method you choose to promote best practices may itself help you identify a best practice in your organization’s culture.

And so, too, it is important to identify and document you worst practices? Worst practices? What the heck is that? And why on earth would you record embarrassing failures? First, a definition: worst practices are those embarrassing gaffes, or the horrible failures that you would never, ever want to experience again. So why remind yourself? As I said before, you can't repeat what you don't document. There are some experience that you will not want to repeat, thus it is important to document these as well. And you are not documenting these best and worst practices for your own use, but those team members who follow you.

¹ Thomsett, Rob, "The Care and Feeding of Project Managers," American Programmer; Vol. 11, No. 2 (February 1998), pp.5-11.