Is Software Quality Job One?

Imagine this: You stand in front of your software-development group and demand that the next release of your Customer Magic application be "built to last." Yes, you want it in a timely manner at a reasonable price, but you're tired of being an unsuspecting beta site. You want the team to start from scratch with the intent of delivering high-quality software--stuff that runs as promised without a crash or error for a whole week!

Before you can mutter the obligatory caveat revealing your appreciation for the additional cost this approach will demand, the head of your project-management team interrupts to say, "Excuse me sir, that solution will cost less."

Did she say less? Surely, she must be confused.

"No, sir. Actually, we've done the math and studied this in some depth. If we focus on the front end of the life cycle, we can actually minimize the building and testing phases enough to reduce the total project cost while at the same time still improving quality. However, it will take courage."

"Courage. What do you mean?"

"You have to be patient enough to wait for the build and test," she continues. "We will not write or test a single line of code for four months. We'll spend that time architecting and refining the requirements set with you and two other tactical users of this product. After the four months, you must have the courage to approve and freeze the requirements and then wait for the delivered product. If you do that, we'll shave two weeks off the original 10-month schedule, save you 8% off the total cost, and deliver code that will run for 30 days without a critical or serious error!"

So, how does this software mini-drama turn out? It all sounds reasonable, and we've been told for years that requirements stability holds the key to software management and quality success. But it's difficult to be patient and even harder to get excited about the requirements rather than the product.

Consequently, the IT industry has attempted many variations of the rapid application development approach. Our data suggests that if RAD is defined as developing an early system prototype as a means of refining requirements, then it can be very effective. However, using RAD as an excuse to code early and put the prototype in production often works counter to the intended result--elongating the schedule and accelerating the bug rate.

Benchmark data from a financial-services sector client provides some hard facts that demonstrate how a focus on the early stages of the software life cycle can yield high-quality results and cost savings downstream. A benchmark of 17 projects taken from the firm's trading-desk and portfolio-analysis applications provides the foundation for our example of the low-cost, high-quality solution.

The projects were developed for the new client group that was insistent on a disciplined approach to software requirements and high-level design. They sent their trading-floor staff to a meeting where they worked side by side with the creative folks from development on the art of requirements definition. They offered their subject-matter knowledge to assist in defining customer satisfaction from the perspective of the user, while still negotiating hard for the features they believed were must haves. In the end, the development team had a rich requirements set that enabled it to focus on software construction. Members used history to determine if the original deadline was feasible relative to the requirements set and evaluated all what-ifs in advance of final budget approval. They also had a written sign-off regarding what constitutes customer satisfaction and acceptable quality.

The results were convincing. The development team spent 36% more time on requirements definition and high-level design than the industry average. But the payoff in the building and testing stage was dramatic. The team reduced the total time by 40% and the budget by 17%, while delivering products that ran defect-free 70% longer than average. And, by the way, schedule performance was in the top 20th percentile of the industry sector.

Sound too good to be true? Interestingly, it didn't happen overnight and it wasn't organizationwide. The benchmark was completed one year after training and practice with these methods on smaller projects. However, the sample performance was significant enough to garner the attention of the CIO, who supported the rollout of this approach on more than 50 projects the following year.

The most difficult challenges in replicating this success may in fact be cultural. We have a hunger for bigger and faster in this society, and we often lack the patience or luxury to wait for a high-quality product. Perhaps our offshore vendors will do it for us. Perhaps our outsourced suppliers and packaged software providers can deliver on this promise of high-quality applications derived from disciplined practices. Or maybe, just maybe, we'll learn from the lessons of the U.S. auto industry and recognize that we need to design quality into our software products up front and stop trying to achieve it through expensive iterations of "build, test, and build again."

Ira Grossman is the CEO of Emergeon and the founder of the Software Genome Council, a membership organization focused on improving software development through metrics. His E-mail address is [email protected].