Everyone complains about bugs in their software. Some can be tolerated, but many go beyond annoying and cause productivity losses. If it’s bad being the user of buggy software, think what it must be like being responsible for quality assurance at a software supplier. Yet, Bernie Beaudoin, quality manager for Sydney, Australia-based software developer, Citect, says, “I’m excited to go to work in the morning. It’s a lot of fun.”

Is there something wrong with him? No. It’s the application of a software development and management tool called eXtreme Programming (XP) that has made him feel this way. Software users have various levels of programming expertise, from basic to skilled, but the ideas behind eXtreme Programming can benefit all levels of users. XP applies some simple rules, like listening to the customer, not making things overly complicated and working in teams, that can make all the difference in the world.

Beaudoin spent a lot of time in software development for the U.S. Navy and became very familiar with military standards. He enjoyed the rigor that they demanded but not the heavy weight of documentation and requirements that had to be attached.He was introduced to agile programming methodologies while working as a process manager for the 1998 Sydney Olympics.

After the Olympics assignment, he returned to the United States to a company that used XP, where he was excited by the quality of software developed there. It was a lot of fun, he says, seeing the process work. That process included:

• Developing lightweight specifications

• Using test cases before developing actual code

• Wrapping the overall systems testing around the process while developers are coding, so that better code is built

• Incorporating the customer all along the way.

Quality assurance

Product development and manufacturing require a formal process to ensure quality parameters are met. These requirements are typically fulfilled through quality assurance (QA) and quality control (QC) programs. There is a big difference, however, between the two. QA starts at point zero on the project map. It involves planning for quality up front and requires an upfront investment. QC is performed after the product is developed. Functional and system tests are constructed, and the product is put through its paces after it is essentially finished.

In software development, quality control may appear to be faster than quality assurance, because code can be “finished” and put through testing. The problem, however, is that it is impossible to develop tests to foresee every condition that the software will face. That means that there can be no assurance that a software product will be bug-free. A programmer may say something like, “I’ve developed and tested each of my functions. Let’s just throw them all together and see what happens.” Perhaps one function chews up a lot of memory. This may not be noticed with an isolated test, but it will cause problems when used as part of a larger functional testing program.

When quality is built in from the beginning, upfront development costs may be higher, but these translate into higher profits by reducing after-market support and improving customer satisfaction. Beaudoin states that when the QA approach is complemented by agile methodology, the results are “phenomenal.”

The XP approach is outlined in the “12-Step Program” box below. Successful application at Citect includes: user stories; constant testing; interactive discussions with customers; and frequent updates of changes.

User defines software

User stories begin the process. Similar to functional specifications, these stories describe what the customer wants to accomplish with the product and how it will be used. The stories are constantly refined during the entire development process. One element of this approach relative to coding is that development is done in modules that can be viewed frequently. At each viewing, customers compare the module to their story and refine as needed, eliminating surprises as the project nears completion.

Contrast this with a typical product development process. The customer dumps a huge document of functional specifications on the project manager’s desk. Developers go into hibernation and begin writing code. As the completion date draws near, the project switches into frantic mode. There is never enough time to do all of the functional testing before the software’s ship date. Now the customer is brought back into the system for final review. After all this time, original assumptions are forgotten and expectations have changed. The result is surprise and dismay from the customer.

This can be avoided with frequent customer interaction and regular testing during the development ...