XP is an agile development process that starting spreading in the development
community after Kent Beck’s superb book ‘Extreme Programming Explained –
Embrace Change’ was published in 2000. In Feb 2002 the
Agile Alliance was formed, and the term ‘Agile’ was born to describe
lightweight processes, one of which is XP. This article describes some advice
on how to help make XP a success if you try to implement it.
This article is targeted at developers and team leaders who are considering
trying XP, or are currently implementing XP. The advice given is based purely
on experience in the field doing XP.
Refactor, Refactor, Refactor.
In my opinion, this is one of the major reasons why an XP project can fail. If
you do not refactor your code all the time then code rot sets in very quickly
and you are doing nothing more than glorified hacking. You must refactor
your code as early as possible, as soon as you see a code smell, and you must
. If you don’t the smells will pop up and bite you in the ass and significantly
reduce your project velocity. I speak from bitter experience on this from my
early XP days. As team leader I foolishly asked the project manager if we
should invest 3 days refactoring, or put it aside. It never got done, and 5
weeks later we realised we had to put 6 weeks work in to fix it. A word of
advice: don’t put refactoring tasks in your project plan if you have the type
of project manager who is not into quality and focuses on features, features,
features. They never chose the refactoring. Refactoring should never be put
aside as a separate task. It is an essential part of the development and should
be factored into your estimates.
These days when the team codes we use the commenting feature in VS.NET to
highlight areas of code that need fixing up. We use TODO to mean ‘it must be
fixed to complete the development task’; STUB means that ‘we have stubbed
something out in order to get the test to pass’. QUESTION means we are not sure
of the requirements and we need to speak to the customer. We never allow more
than 10 todo’s to remain in the code which are reviewed continuously to remove
them. All questions need to be resolved as soon as possible, even if it means
picking up the phone during development. Stub’s get removed as we evolve the
Good Time Management
Pair Programming all day is intensive and
can be quite mentally exhausting. It is important for the team leader to
schedule the days activities to optimise the best use of high and low brain
time. We code from 9am to 4pm, breaking for 30 minutes agile design sessions
(one test case at a time) when required. After 4pm we don’t trust ourselves to
write good code, so we spend the low brain time clearing up any easy
refactorings that have been flagged during the day. Things like method
renaming, or removing code duplication. It also gives the team a chance to
catch up on their emails and other things. Avoid meetings during the day. 9am –
4pm is coding time! Leave any low brain meetings until later in the day.
Test Code Quality
The quality of the test code must be of as equal high quality as the production
code. Your test code is your oxygen. Without those tests you are horribly
exposed. Make sure the tests are refactored with as much rigor as the
production code. Expect to have as much test code as you do production code, if
Get Good People
This does seem a bit obvious, but it is important. Doing XP means that you are
continuously refactoring. If you are continuously refactoring then you need the
developers to be good engineers so they can spot the code smells early and do
something about then. You need to ensure that they don’t write poor quality
code. If you have an odd number of people on the team and one of them lacks the
skills then don’t let them code on their own because they will write code that
needs to be reworked. I call this introduction of code smells ‘refuctoring’. A
classic case of this is if you have modular programmers on an OO project. Don’t
leave them on their own to code. It will need redoing. A common mistake by
project managers is hiring modular programmers for an OO project and expecting
them to suddenly code OO. It doesn’t work.
Also, on this subject I strongly recommend having only one student on the team
at any time. That could be someone new to XP or new to OO for example. They are
s tudent until they have learnt enough to be able to teach someone else. Any
more than one student and it slows things down. Also, don’t let students code
together either. They tend to know how to write tests, but no idea about what
tests to write and at what depth. You end up having to rework their code.
The best fit is 4 good software engineers with plenty of development
You are going to have to change your code as the requirements move. To be able
to do this you need to very well designed decoupled architecture. It makes
making those changes so much easier. You don’t need to go overboard and spend 6
months building a big framework or anything, but I would suggest starting with
an architectural spike so the team knows where they are heading
architecturally. Quad program the first test case as well. This ensures the
whole team understands the architecture.
Keep Light On Tools
Don’t waste time drawing nice fancy pictures of your designs using the latest
buzzword compliant modelling tool. Get a whiteboard and a digital camera. It is
quicker. Use a Wiki for project documentation.
Build the system one test case at a time. Don’t start trying to wander off
whilst you are in the code and start guessing other code that needs to be put
in. E.g. While writing a collection you might think ‘oh, I might as well put in
a count method’ etc. Don’t! Only write code if the tests tell you to. Get the
one test passing, refactor the code, and move onto the next text case.
Make sure you conduct some modelling before building anything. Granted, this
might be contentious advice, since many rumours say that you don’t do design
with XP. That’s not true. Design is good, provided you don’t get carried away
and try to do too much without proving it in code. What XP says is that you
shouldn’t spend ages drawing fancy pictures of what you are going to build, but
instead you should build it. XP acknowledges that no amount of design work can
prevent changes being required when you build it.
I strongly suggest you practice what I call small model up front (SMUF). In
small model up front you choose a test case that you are going to try and
build. You identify the initial conditions, triggering event, and expected
outcome. If the screens are also key then you draw pictures of the screens
before and after the event. You then draw object snapshots of the key parts
before and after the event. Next you knock up a sequence diagram of how it is
going to be achieved, and then after that you draw a class diagram of any
changes to the class model. You then take a picture of the whiteboards, put it
on the wiki and try and build it. The whole thing takes anywhere from 10 to 30
minutes. I often find that when we try to build it that the designs had flaws
in them, but these would not have been spotted without trying it out in code.
That’s the whole reason why we try to get to code quickly in XP. There is no
point spending ages drawing fancy pictures when we know things will change
You must pair program. You have not done enough design before the build to get
things spot on, so you are going to have to make design decisions during
coding. These are best done with two people. Pair
adds significant quality to the code, and minimises the need to rewrite code.
Formal code reviews are far too late in the cycle, and need be avoided (if you
actually ever did them). When pair programming make sure you know what your
role is. The driver is fairly obvious, but the navigator needs to be navigating
and thinking of the bigger picture rather than just annoyingly telling the
driver what to type. Make sure you swap the pairs about so everyone gets to
learn all areas of the code. Pair programming is great for teaching students.
Make sure that you always have a working build of the system. Getting a
continuous integration server up and running is well worth the effort. You must
have a working build that you can show to the client at all times. If the build
breaks then everyone in the team must work to fix the build before carrying on.
You don’t have to have continuous integration up and running from the start,
although it is handy if you do. If you can’t get CI running, then at least make
sure that any checked in source code is integrated and tested before it is
checked in. Poor configuration management will result in failure, whether you
are doing XP or not, just more so for XP.
Because you are doing XP, you aren’t spending lots of time writing requirements
documents. Therefore you must ensure you get continous feedback from the
customer. Getting an On Site customer is ideal, but rarely possible. Having
formal reviews every couple of days for half an hour will help out. You must
have these reviews. If you don’t, you run the risk of wasting time building
stuff that isn’t what the customer wants. Remember, these meetings are where
you confirm requirements and solicit further ones. You haven’t done lots of
requirements analysis and design up front, so you need to have these meetings.
Get Testers In Early
In traditional development formal testing tends to be done at the end. This
runs the risk that bugs could be found that could result in major rework to
resolve. The earlier bugs are caught, the cheaper they cost to fix. I would
advise getting a tester on the team from the start. They can then understand
more about the system and get a better feel of what to test. Remember that if
you put it at the end it will cost more to fix and you will also have the
problem of imparting the intended use of the system on them without any
Tests Must Run Quickly
Your tests must run quickly. When I say quick, I mean all tests preferably in
under ten seconds, and at most one minute. Once they start taking too long to
run it slows down development. If you have a lot of database access code which
is slow then make use of Mock Objects to speed things up. If you are writing a
web app then you need to work out how to test the front end without having to
fire up the browser. I’ve written automated browser tests and although not bad,
they are too slow. [I’ll explain how to test web apps without firing up a
browser in a future article. I did this recently using a two stage view
technique with XSL transforms, together with a Mock httpContext object. Instead
of taking 25 minutes to test the application, it now takes 12 seconds.]
Have daily morning meetings that last 10 minutes maximum. Everyone must share
with the rest of the team what they developed the day before and also explain
what they are intending on doing that day. This essential communication is
important for brainstorming and sharing ideas.
Communication, Communication, Communication
You have reduced the amount of documentation. You have reduced the amount of up
front requirements analysis. You have eliminated the big model up front design.
The only way to replace these is by good communication. Don’t waste time
sending emails that can be misinterpreted. Infact, ban email if you can within
the team. Go and meet people and speak to them. Get everyone talking all of the
time to share the knowledge. Daily meetings, On-Site customer, Pair
Programming. All these activities are part of the communication. Do them, and
do them lots. You’ve got to make sure you build the right thing, and build it
well. Lots of effective communication is key to make that happen.
Don’t Do It All Straight Away
Don’t try and do it all in one go. Introduce aspects of it one at a time. My
article Moving to XP
gives practical advice on how you can do this.
Get A Mentor
If you are going to try Extreme Programming with no mentor to guide you then
your chances of failure are higher. There is a lot to learn, and it is unlikely
that you will do it all right first time. If you have the sort of manager who
will ban XP at the first sign of failure then you really do need to get
yourself a mentor to help you out. If, on the other hand, your PM appreciates
you are trying something new and accepts that mistakes will be made, then go
Good luck, and happy developing.