Quality Vs Speed: Paradox Lost? - Article

(Page 2 of 3 )

The "Software Development Paradox"

A paradox is a condition that embraces two apparently contradictory facts, but the contradiction disappears when you look at the problem from a different perspective. The most famous of these conditions is Zeno's paradox, involving a race between the Greek hero Achilles and a tortoise.⁴ The tortoise gets a head start, and apparently Achilles can never surpass the tortoise because whenever Achilles runs to where the tortoise was, the tortoise has gone further ahead. While Achilles makes up that gap, the tortoise creates a new one. As long as Achilles' forward progress is defined in terms of the turtle' progress, the paradox appears unassailable. However, as soon as we think of both Achilles and the tortoise progressing toward the finish line, the paradox disappears.

So then, where is the change of perspective for the software paradox? How could speed and quality be in conflict at the beginning of a sales presentation, and not by the end of it? In thinking about this, I felt the change had to be found in the definition of one or the other of the two terms. "Speed" was fairly straightforward: it was developing software fast enough to hit a rapidly approaching market window -- a window that was usually also narrowing as it approached. But what exactly was "quality"?

Quality, Defined

Writers reflecting on the term "quality" often refer to Robert Pirsig's thought-provoking book, Zen and the Art of Motorcycle Maintenance, ⁵ which has much to say about the relationship of a technician to her or his work. (The discussion of how to produce good technical documentation is extremely worthwhile.) However, Pirsig claims that "quality" exists in the way individuals perceive the subject-object duality, which underlies the very idea of defining things in the first place.⁶ While that's intriguing philosophically, it seems to have little if any relationship to the use of the term "quality" in the IBM Rational software development paradox.

Gerald Weinberg offers a much more practical definition: Quality means "value to some person."⁷ This fits much better into the realm of defects and customer satisfaction. A defect can be associated with decreased value to some person -- the customer. Customer satisfaction becomes a measure of the product's value to one or more persons.

Still, there's something missing for me in this definition of "quality." In my experiences with products, I have noticed an odd phenomenon: Value tends to vary over time. For example, most of the textbooks that I carried and pored over in college are now not only worthless in the marketplace, but also of little interest to me personally. The larger the period of time I consider (e.g., from my childhood to the present, when the toys I once cherished are now unimportant), the more likely it seems that the value of any given thing diminishes. Mission-critical software I wrote twenty years ago is of no use to anyone today.

So, although Weinberg's definition is good, perhaps "quality" might be better defined for my purposes as "value to some person over some period of time." In addition, Weinberg's definition might also be modified to expand the reference beyond a single individual: Quality is "value to some group of people over some period of time," where the group can be one or many people, and the period of time can be arbitrarily small (as with a market window) or large (as with the lifetime of a product).

The Paradox, Revisited

Now, we can apply this more satisfying definition to the software development paradox. Notice that "quality" and "speed" both relate to time and value. "Speed" is generated when the development staff makes decisions in favor of maximizing value during a market window; "quality" is generated when those decisions favor maximizing value after that window.

If all decisions only consider the next market deadline, then the staff becomes Achilles in the paradox, always hurrying to the next immediate goal, but never winning the overall race. If instead they fixate on long-term value by itself, they become the tortoise, winning the race in theory (perhaps) but generating no excitement. Achilles wins by focusing on the finish line, and being speedier than the tortoise; development teams win by delivering quality in each release as well as across many releases. Teams should be able to build products with both the excitement that comes from delivering new features when customers want them (when the customers value them) as well as building products with the steady value of defect-free operation between releases.

That was how the paradox disappeared! There is no fundamental reason why a product cannot have high value at its introduction (when customers want the product because it's new) and thereafter as well (when maintenance renewals are due, for example). Teams don't have to choose between speed and quality, picking either on-time delivery of buggy code that will be a maintenance nightmare and will anger customers or code that works perfectly but no one wants anymore. Value can carry on beyond the end of the market window, like Achilles striding past the tortoise. (Walker Royce offers a comprehensive discussion of this point.⁸)

However, this led me to a new problem: If speed and quality were actually not mutually exclusive, why did so many people feel that they were? After all, their feeling agreed with my experience: in my twenty years as a tester (prior to joining IBM Rational), all the teams I had ever been on had struggled with choosing either value that's timely or value that lasts, but they were never able to have both. How could it be otherwise? It might be possible to define one's way out of the software paradox, but the opinion and experience of so many people in our industry can't be lightly dismissed.

Thinking back on the puerperal fever epidemic, I surmised that, just like the physicians who were unwittingly causing the deaths of patients they were trying to save, so too software development teams were probably themselves causing the failure of their projects by trying to save them. The problem arose because each attempt to "save" a project focused on either the speed-to-market imperative or quality of product, but not both. For instance, when a team emphasized speed, they typically took shortcuts in the processes and communication that otherwise would have led to quality or lasting value. On the other hand, emphasizing quality could easily cause a team to spend too much time on artifacts that communicate little, and processes that hinder reaching a reasonable ship date. Either approach is fatal to the project.

The IBM Rational approach does indeed solve the supposed paradox. Integrations between Rational tools eliminate much of the time-consuming overhead of communication between team members, thereby both speeding the development process and allowing the remaining communication to focus on long-term value. The Rational Unified Process^®, or RUP,^® product eliminates a great deal of time lost in communication by standardizing, documenting, and providing detailed online guidance for the roles, activities, and artifacts that are involved in the development lifecycle.

The use of RUP can also keep the market window within reach while permitting the team to focus on customer satisfaction -- or better yet, long-term customer success with the product. Tools that can be used to ensure high-quality artifacts have the side effect of reducing wasteful communication, too, because no one needs to discuss why the artifacts are poor, or what to do about it. Success leads to more success, which leads to the almost unbelievable results, such as ROI in the 800 percent to 2000 percent range, reported by IBM Rational customers.

Next: Notes >>
 

More Development Cycles Articles
More By The Rational Edge

Comments On: Quality Vs Speed: Paradox Lost?

>>> Be the FIRST to comment on this article!