XP Software Programming Paradigm
Guide to extreme programming, agile code, scrum programming, team programming and other XP principles.
This article describes the key features of Extreme Programming, and how it benefits the customer, programming team, and end product. Start here for XP.
Introduction
Extreme Programming (XP) is a software creation paradigm, covering the key areas of software development:
- Specification;
- Design;
- Development;
- Testing.
However, XP goes beyond the remit of competing paradigms by also adressing:
- Communciation & Planning;
- Code Management.
In short, XP tackles the entire development life cycle, from initial concept through to testing, delivery, and enhancement. This makes it ideal for fast moving projects, or ones where the original concept is open to change during the life of the project. The early release mechanism means that the customer gets more input, making this last more likely to happen.
The reasons for this will become clear, but are linked to the innovative relationship that XP fosters between the customer, programmer, between programmers, and between everyone and the code being written. Some concepts related to XP include:
- Agile programming - fast, flexible development paradigm, often considered part of XP;
- Scrum programming - follows the same paradigm as XP i.e. frequent progress check-points;
- Pair programming - one of the core XP practices;
- Iterative development - loosely defines one of the XP practices;
- Team programming - like pair programming, but involves everyone; key to XP.
We will look at three important areas in XP - the Client, the Team, and the Patterns. The first two will be reasonably familiar, but the Patterns aspect introduces some reusable concepts which make XP a repeatable exercise.
Extreme Programming and the Client
The most obvious benefits to the customer are those of high quality deliverables, a higher level of interaction with the developer due to frequent releases, and lower cost of failure. Coupled with a lower failure rate, and more flexible, yet achievable planning goals, it makes a very interesting proposition.
Part of the interaction occurs because XP approaches the functional description of the system using customer stories rather than techncial use cases. This means that the customer writes down what kind of experience they wish to have, as a story in their own terms, and the developer must then interpret that into a suitabel design that the customer will understand.
This can be extended to the development process itself. If the customer is an internal client, and the developer a department in a larger organisation (say auto manufacturer), then the entire process can be defined using a system metaphor. In other words, the process is described in terms that an auto manufacturer understands, rather than remaining abstract; which it will if the project is being developed by programmers. Abstraction is something they understand.
In orer to maintain this high level of interaction - good, because it ensures that the right product is developed - some practices need to be adopted. These include small, incremental, releases, designed to allow the customer the time to play with the work in progress and provide feedback on it.
Extreme Programming Teams
XP brings some innovations to the actual programming teams, as well. The most innovative of these is pair coding (team programming). Pair coding is vital to XP, because it provides a mechanism whereby maxiumum efficiency is extracted from the time available. Each pair codes as a single entity - one writing the tactical level code, and the other cross-checking with the overall strategy - but approaches the problem at two complementary levels.
Pair programming is used in conjunction with collective code ownership, where any pair can change any part of the system. This is only possible thanks to the innovative test patterns which we shall cover later on. Using these test patterns essentially ensures that only quality code is returned to the code base.
However, in order to make sure that the code does not become monolithic (with classes having multiple, diverse responsibilities), some advanced XP principles are reqiured:
- Small units - no large, multi-purpose classes;
- Frequent integration - no time to make 'big' mistakes;
Integration implies testing; only good code makes back into the code base. Frequent means hourly, not daily. The result is extremely agile code.
This also needs to be coupled with intelligent reuse; making sure that the wheel is not re-invented, but only when the new wheel is compatible with the old one.
Finally - no overtime! Overtime is bad, and leads to high staff turnover, and disgruntled, low quality, low efficiency, coders. Not always, but enough to make the no overtime rule a good one.
Extreme Programming Patterns
In order to keep all of the above running smoothly, XP adopts some patterns of programming management:
- Spike solutions;
- Stand-up Meetings;
- Refactoring;
- Testing.
These patterns are reusable across multiple projects, approaches, and even industries - they are not pure XP, but are used by XP. Spike solutions are just small explorations into possible solutions, from which the best fit is chosen. Most alternatives are thrown away in the process.
The Stand-Up meeting has two major sides to it. One, the participants are not allowed to sit down. Two, they rarely stop moving or talking. They are constantly in conversation, putting stickies on the wall, jotting on whiteboards, getting feedback from at least two parties. The meetings look messy, but they are surprisingly effective and dynamic.
Reuse was a watch-word in programming circles, and still is. XP prefers to tackle reuse by refactoring. Constantly paring the code base down and throwing away things that do not work die to new requirements, and even throwing away things that do work in favor of ones that are more meaningful in the updated context. Like stand-up meetings, it feels messy, but does work.
The last pattern relates to Testing. XP testing starts before the code is written. In other words, the test harness is created before the code under test. Each piece of code passed back into the code base has to pass all the tests at 100% if it is to be included. New code exists as a test before it exists as a solution. The only way this approach works is if everyone in the project embraces the XP paradigm entirely, which can be the hardest part of adopting XP.
Summary
Extreme Programming is a relatively new, untried, exciting paradigm for software creation. It is true to say that the real fruits of the hard work involved in creating the paradigm have yet to be seen. However, those teams that have used XP in the field, and are feeding, in true XP fashion, their results back to the community, report that it has changed the way they code.
It is clearly not for everyone. Bedroom coders, small outfits creating specialised products, and those maintaining huge industrial code bases with a skeleton programming staff will find no help in XP. Those invloved in fast-moving, new, high-technology projects, will. Of course, there is also something to be said for refactoring those monolithinc code bases in an XP way, but it is unlikely that the return would justify the investment if a system is being replaced by an XP coded version anyway.
Finally - people are resistant to change. Existing paradigms have 'worked' for so long that adopting XP may be hard to sell, but concentrating on the benefits to the customer will usually win the day.
