How to achieve "zero bugs." (advice from TurningPoint Systems Inc Pres Ken Tepper) (Technology Information)

When software ships with known bugs, argues Turning Point president Ken Tepper, it's almost always because testing and bug-fixing were deferred until too late in the development cycle. "Programmers by nature want to keep their momentum going," Tepper says. "They'd rather move on to new functionality than test code they've just finished--even though it always takes longer to fix bugs when a project is nearly done."

Tepper, who runs a 13-year-old contract programming shop with a long list of blue-chip clients, says that putting off any bug fixes--except perhaps for glitches caused by defective programming tools or design problems--is a dangerous practice. He's convinced that the right way to build commercial software is to insist on a "zero bugs" standard--which means that programmers aren't allowed to start a new task until they've tested and cleaned up every discoverable bug in code they've just finished. "If you prevent someone from moving on until they check in good, solid code, there's a real message there about quality," he points out.

Tepper admits that his approach sometimes sounds extreme. "There were a lot of objections here when we started our "Zero Bug Initiative' three years ago," he says. "We weren't really sure it would work, especially on projects where the schedule was slipping. But I think everyone has been convinced by the results. You really see the value at the end of a large project: We'll have maybe 50-100 bugs in our bug database now, compared to 2,500 bugs that usually had to be cleaned up when programmers were allowed to move on without fixing everything."

Tepper says his "zero bugs" method relies on several principles that can help produce squeaky-clean code:

* Insist on unit testing: Although Turning Point has a group of specialized quality assurance engineers, Tepper says individual programmers still have first-line responsibility for testing their own code. This "unit testing" approach pinpoints responsibility for bug fixes and performance, and it helps ensure that low-level code works properly before higher layers of functionality are added.

* Integrate QA into the project team: Once code has been unit tested at Turning Point, it also undergoes formal testing conducted by quality assurance engineers, who join the development team at the earliest possible point. "QA people should be on line as soon as coding starts, and ideally during the design phase," Tepper argues. "QA people can't take a piece of unfamiliar code and just start testing it--they need to be familiar with the whole project."

* Establish formal coding standards: For every project, Turning Point's team leaders set standards for common coding conventions and style. "At the most superficial level, this guarantees maintainability," Tepper points out. "Beyond that, there are things we've learned--such as using asserts liberally--that make code much easier to test and more robust." (Tepper also encourages his programmers read classic texts on Programming technique; his favorite is Steve Maguire's Writing Solid Code.)

* Conduct frequent code reviews: Turning Point's senior programmers regularly browse through randomly-chosen chunks of code, checking for stylistic consistency and proper programming techniques. "It's surprising how often they find bugs just by reading the code--and these are often bugs you wouldn't spot with mainstream testing techniques."

* Run Debug Windows: Tepper says an often-overlooked test is simply to run new code under the special Debug version of Windows, which reports bugs on a second monitor. "We've looked at some very popular shipping programs and been amazed," says Tepper. "You see all the stuff that developers let through that are so easy to catch."

* Maintain separate debug and ship builds: "Bugs are much easier to identify in debug builds and some bugs won't show up in ship builds without extensive testing," Tepper says. "Conversely, performance and memory usage are not representative in a debug build and some bugs won't occur in debug builds that do occur in ship builds."

Ken Tepper, president, Turning Point Software, One Gateway Center, Newton, Mass. 02158; 617/332-0202.