{ END BRACKET }

The Pay as You Go Model

Eric N. Bush

How would you feel if you were having your dream house built, but when you inspected the house you found some fairly obvious flaws in the work—cracks in the foundation, support beams missing, crooked and leaning walls. Then to make matters worse, the construction foreman walks up to you and says, "Isn’t it beautiful? And we’re even right on schedule. And by the way, don’t worry about those apparent flaws, we’re just about to move into our quality phase and rip everything apart to set things right."

Not only would it take much longer to build a house this way, but the foreman would also have a high degree of customer dissatisfaction. As software engineers, one thing we must insist upon is quality right from the start. If we don’t pay the price to build in quality as part of a continuous process, then we must pay a much higher price attempting to test it in later.

In some companies, developers are given a very short coding phase followed by what is termed a very long "stabilization" phase. Most of the time in "stabilization" is spent trying to clean up the mess they got themselves into during the insanely compressed coding phase. In order to meet this compressed timeline, code inspections, unit testing, and other essential practices are tossed aside. The definition of "code complete" under these circumstances is extremely lacking. Nothing works for a stretch of time until features start to stabilize little by little. The project eventually reaches some measure of quality, but it is not as high as it should be. We can call this the "test in quality" model. Working under these conditions is very demoralizing to a team and causes high levels of worker stress and burnout.

Teams need to follow a "pay as you go" model. The battle cry should be "start stable and stay stable." Features must go in completely tested and working over a greater expanded coding phase. Slowing down and doing things the right way is really the key to speeding things up in the long run. It is much better to have 80 percent of development time spent in coding (in a continuous quality manner) and leave 20 percent of your time at the end for verification. "Code complete" in this model really means something.

One way or another there is a price to be paid for quality. You can spread that cost evenly across the complete development cycle, or pay a much higher cost later and attempt to test in the quality at the end. It makes much more sense to build in the quality right from the start. The benefits are incredible—higher final quality, shorter overall schedule, higher team morale, consistent working builds, realistic estimates, and, of course, increased customer satisfaction. You can calculate the fixed cost of the engineering overhead needed to follow a strict process for building in quality. You can’t, however, predict the cost of searching for and fixing all the issues with a "test in quality" model. In those cases, development is only putting in enough hacks to get the product out the door and is not really fixing the code to make it solid. It is best to establish expected good behavior right from the start of the project.

Get started by creating a project plan that gives the details of your quality goals and how you will reach them. This plan will explain how you are going to address the performance, reliability, instrumentation, security, and maintainability of the code. Then, as you sit down to write your code each day, you should have the following process checklist handy:

• Keep in mind the quality goals
• Follow team coding standards
• Use defensive coding practices, including input validation and proper error handling
• Run static code analysis tools
• Run dynamic code analysis tools, such as those for reliability and performance profiling
• Create and run associated unit tests for all your code
• Hold regular code inspections/reviews
• Do buddy builds and simple build verification tests
• Refactor code for maintainability, simplicity, consistency

Never make a check-in without meeting that standard. The goal is to have a stable, ready-to-ship product every day. When features go in, there will be no question as to their readiness. This model is much more efficient and it fits in well with other agile ideas, such as having shorter milestones along with having better defined quality checkpoints. Make it a practice to build your house the right way, with quality built in right from the start. In following the "pay as you go" model, your company will be in a greater position to not only innovate but to grow as well.

Eric N. Bush is a software development lead in the Engineering Excellence group at Microsoft. He works as an internal consultant and classroom instructor driving engineering and organizational improvements in the areas of people skills, process, and technology. Reach him at ericbush@microsoft.com.