Improve competitive quality with extreme programming

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 stages. This assures better quality, less final system testing and a shorter project timeline.

There are two types of testing required for a software project: functional test of pieces of code and system testing. XP holds that both tests should be done often, daily if possible, and should involve developers as well as quality assurance testers. Developers first develop the functional test for the object that they are working on, code it and run the test. If the test is successful, the object goes into the code base. The test code may just be temporary and eliminated at this point, or it may be saved and incorporated in tests for similar objects.

Quality engineers develop the system test at the beginning of the project. Functional test cases and code are wrapped into system testing, so that as daily testing proceeds, the overall test base keeps growing. On the human side of things, this requires constant communication between tester and developer. They work together as part of the team, not as adversaries. Testers are involved at the coding stage, so they are familiar with the code and how it was developed. On the software side, pieces of system testing are done constantly, the test is revised as necessary in order to reflect new realities, customer input is incorporated quickly, and good code is produced sooner than with other methods.

One weakness of traditional programming methods, according to Beaudoin, is the adversarial relationship created between programmer and tester. Every programmer believes that he or she is writing perfect code. Yet, the testers find all those bugs. With the XP process, the tester is the programmer’s buddy, working right alongside at the same keyboard in a cooperative, rather than competitive, relationship. When compared to traditional methods, the XP approach also requires fewer product testing engineers. Beaudoin uses only four pairs (eight total people) for all product testing. He states that this relatively small test team can turn out a lot of high quality testing because of the XP method. “Integrating the process into teams has been an integral part of our XP effort,” he says. “It really gets the programmers enthused about testing and quality. This is a new way of doing things, but it’s not a religion. It’s a philosophy that is constantly evolving. We’re probably one of the few real-time environments using XP.”

Stand-up meetings

Another aspect of XP is the daily stand-up meeting. Teams meet, literally standing, and each member in turn has a few minutes to discuss a problem or a success. The whole process takes 10 to 20 minutes, but it keeps everyone informed about progress. Managers often attend to stay in the loop.

Beaudoin says, “This is a lot of fun. We start out with a management stand-up meeting, and then I meet with my team. It’s quick and productive. If I receive a change in direction from management, then I just go back and tell them that we’ve had a little change in priorities. What can we do to help out? They’ll usually say that the current work can get done with fewer people, so we free them up for the new task.

“At the end of the day, we see robust testing leading to fewer customer complaint calls. In fact, many callers say what a great job we did rather than the usual critical calls a quality department gets.”

Citect bills itself as the largest independent supplier of industrial automation software with over 30 years of experience developing human-machine interface and supervisory control and data acquisition (HMI/SCADA) software and industrial information management systems

Its latest release (version 5.42) of CitectSCADA is the first developed using XP methods. This version includes automated diagnostic tools that capture customer system information for analysis, speeding resolution of customer problems.

12-step program

The eXtreme Programming methodology advocates a 12-step program to minimize software bugs.The organization’s Web site, www.extremeprogramming.org, discusses these in detail.

1. Develop user stories. These create time estimates for the release planning meeting and are used instead of a large requirements document. They are written by the customers as things that the system needs to do for them.

2. Hold a release planning meeting. A release plan, which lays out the overall project, is created at this meeting. The release plan is then used to create iteration plans for each software version.

3. Create the release plan. This specifies exactly which user stories are going to be implemented for each system release and specifies dates for those releases.

4. Release small pieces of the system to the customers often. This is critical to getting valuable feedback in time to have an impact on the system’s development.

5. Use iterative development. Have a planning meeting at the beginning of each iteration to plan what will be done.

6. Move people around to avoid serious knowledge loss and coding bottlenecks. If only one person on the team can work in a given area and that person leaves, or more things need to be done in that section, the project’s progress can be reduced to a crawl.

7. Code unit test first. Creating a unit test helps a developer to really consider what needs to be done. Requirements are nailed down firmly by tests.

8. Pair up programmers. All code to be included in a production release is created by two people working together at a single computer. Pair programming increases software quality without impacting time to deliver. It is counterintuitive, but two people working at a single computer will add as much functionality as two working separately, except that it will be much higher in quality.

9. Hold a daily stand-up meeting. Communication among the entire team is the purpose of the stand-up meeting. A stand-up meeting every morning is used to communicate problems and solutions, and to promote team focus.

10. Create spike solutions to figure out answers to tough technical or design problems. A spike solution is a very simple program to explore potential solutions.

11. Keep the customer available, not only to help the development team, but to be a part of it as well.

12. Integrate often. Developers should be integrating and releasing code into the code repository every few hours, whenever possible.

12-step program

Extreme programming methodology advocates a 12-step plan to developing good software products. These are:

• Develop user stories

• Hold a release planning meeting

• Create the release plan

• Release small pieces often

• Use iterative development

• Move people around

• Code unit test first

• Pair up programmers