Extreme programming ensures robust software systems

For the last five years, a software development methodology called Extreme Programming (XP) has been receiving more attention. It is either admired or condemned from a multitude of sources.

Essentially, Extreme Programming provides a methodology for small groups to generate software focused on the needs of the client. XP is the creation of members within the Agile Alliance. These software developers established 12 fundamental principles for programming:

• Satisfy customers
• Welcome change
• Deliver frequently
• Business/developer communication
• Use motivated individuals
• Face- to- face communication
• Measure progress with working software
• Constant work pace
• Attention to excellence
• Simplicity is essential
• Self-organization
• Continuous progress improvement

The canons of extreme programming result from the practical application of these principles. XP can be distilled into these practices, which we consider the major canons of XP:

User stories

• Iterative scheduling
• Test-first design
• Pair programming
• Refactoring
• Continuous integration
• Collective ownership

Each canon is useful in itself; but when used together, they provide the framework for an often successful development environment.

Usually, software is designed from a strict requirements document or, sometimes with no document at all. One of the typical problems of using a requirements document is that it focuses solely on the technical aspects of what must be completed.

In many cases, a development team can implement a design that technically meets the requirements, but does not perform in the best manner for the end user. In addition, it is not uncommon for the requirements document to be loose, which can further remove the end software from what the end user actually needs.

To solve this dilemma, XP creates 'User Stories' to define the goals of the design instead of a requirements document. These stories express the design requirements from the user's point of view: How does the user need to access/manipulate data? How should the data be displayed? What controls are needed?

However, counting against the XP methodology is the fact that not every design lends itself to user stories. There are some designs that are completely specified by mathematics and models. In these cases, a requirement document is the proper method of defining the system.

XP requires multiple releases during the development cycle for client review. This allows the client to review progress early and make suggestions. The client and the developers rate the User Stories by importance to the project timeline. After rating the user stories, iterations are planned during the course of the project. Each iteration ends with the completion of additional features to the existing design. Additionally, iterations should be spaced out regularly within the timeline of the project. Releases are then planned every few iterations.

Iterative scheduling empowers the client, when dealing with the inevidable unknowns associated with designing a new product. This allows one to make tradeoffs between delivery schedule and released feature set. However, with iterative scheduling, there is the temptation to never complete the project because of scope creep, caused by the continual addition or reinterpretation of user stories.

The key to quickly implementing features and ensuring that old features are not corrupted, is to implement tests prior to writing code and to perform all tests prior to and after each integration cycle.

Additionally, it is important to incorporate the new test into the battery of tests used to verify the system. Test-first does not mean that tests are created and never altered. As problems are discovered and the understanding of the user story and application grows the tests must also grow.

Another advantage of this tenet: feature requirements can be further thought through by writing the test code. If it is not being tested, it is not required. Also, once the test code is written, code being developed can be checked for completeness. And once the code passes the test, it is complete. There is a defined stopping point. A side effect of this advantage is that no unneeded code is added to the system. This also reduces the temptation to write the test to fit the code, rather than the requirement and also reduces integration time.

Pairing up
One major deviation from most software methodologies in XP is the requirement for paired programming. This requires two programmers to work together on each piece of code. Further, the two developers should work on the same PC — one monitor, one keyboard, and two programmers.

While some may be taken aback by this, it does have advantages. First, during the development, code must be justified before it is added. This may be restated as 'there is a continual code review'. Also, there is always a sounding board for new ideas.

Refactoring means rewriting code to minimize complexity. Simplicity is the key to a good design. Designs that are unnecessarily complex take an excessive amount of time to understand and debug. This is part of the reason behind not adding features until they are required.

When code is initially written it is written to complete the task at hand. After it is completed, new insight may be found which makes the code less complex. By refactoring, the code becomes easier to understand, debug, and maintain.

However, refactoring may give a developer liscense to continually tweak a design. This drives up development cost, without necessarily much gain. Change for change sake is bad. Also, what is simpler for one designer may not be simpler for another. This may lead to a coding change battle between developers.

As new code is developed, it should be continuously integrated into the overall system and made available to the other developers. Depending on the project, the maximum time between integration should be one to three days. If the time between integration extends much beyond that time period, different development groups may find themselves working with outdated code.

Another reason to continually check software into a central repository on a regular basis: lost code is difficult to recover. If more than three days of work resides in a file and it is accidentaly overwritten/deleted/lost, that becomes three days of work that must be repeated.

One of the pitfalls of software development that XP tries to resolve is the code ownership bottleneck. If only a particular individual works on a class/module/routine, then any changes or refinements must be done by that person. Additionally, this limits the section of code to a particular programmers experience and availability.

XP resolves this issue through the philosophy of 'collective ownership'. The responsibility for the entire design rests with all the designers. While a pair of designers may be the primary contributors to a section of code, another designer may refactor or debug the code.

But, the same attributes that makes collective ownership great, can also be it's downfall. Designers have now been given the right to change another's code. They could accidentally discard work that would have worked but needed only another day, just because another developer didn't understand the code as it was written.

Due to the 'Collective Ownership' canon, there are at least two developers working on a project. If coding standards are not defined prior to beginning the project, the coding styles may be so diverse that the resulting code may be unreadable. But there is a limit to what should be defined in the standards. The programmers shouldn't be restricted from violating the standards, but the violations should be justified through comments in the code.

Between continual refactoring, test coding, task implementation, and constant integration, XP guards against burnout by mandating a forty hour maximum work week, because beyond that time period, developers begin to burn out and their ability to be productive decreases. On the other hand, not every project has an flexible amount of time allowed for completion. XP has the potential to continually extend the schedule. If a deadline isn't occationally fixed and not allowed to slip, constant improvements may keep the pushing the date out.

There are many cases where using XP in a design will benefit the designers and the client. It will help deliver a product truly needed by the client, determine release schedule changes through iterative scheduling, and increases code accuracy by paired programming and refactoring.

When considering XP, one must also be aware of it's associated pitfalls, such as, potential schedule slippage and potentially increased billing thoughout coding.

Almost every developer has used all of the XP development practices in isolation. Even if XP is not fully adopted as the development method of choice, understanding the benefits and pitfalls of the XP canons will allow better use of these techniques to the advantage of all parties.