Making XP A Success

This article is written by Dave Chaplin, an IT Consultant with 10 years experience. He leads and mentors teams of developers on agile .NET projects and has extensive experience in agile development techniques, particularly Test-Driven Development. Dave can be emailed at davechaplin@byte-vision.com.

Date: Monday, April 28, 2003

Abstract

Overview

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 refactor mercilessly . 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 code base.

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 not more.

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 experience.

Decoupled Code

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.

Avoid Wandering

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.

Modelling

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 anyway.

Pair Programming

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 Programming 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.

Continuous Integration

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.

Customer Feedback

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 requirements documentation.

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.]

Daily Meetings

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 for it!

Good luck, and happy developing.

Other Articles

Test Driven Development (Dec 2003)
The Losers Olympics (Sep 2003)
Making Projects Succeed: Part 1 - Measurable Business Goals (Sep 2003)
Pitfalls In Software Development (June 2003)
Extreme Web Architectures - Testing Web Applications In Seconds (June 2003)
Pair Programming and Quad Programming - From Experience (June 2003)
Making Extreme Programming A Success (April 2003)
Contractual Test Driven Development (TDD with DBC) (April 2003)
Moving To XP (Feb 2003)
Maximising Development Productivity (Dec 2002)
Writing Automated Browser Tests Using NUnit and IE (Oct 2002)
Mitigating Requirements Risk With Agile Practices (Oct 2002)
10 Tips for Successful Team Leading (Oct 2002)
Developing Automated Using Tests Using NUnit 2.0 With VB.NET (Sep 2002)
Quality By Design - Part 1.doc (May 2001)
Quality By Design - Part 2.doc (May 2001)
Quality By Design - Part 3.doc (May 2001)

Other Resources

NUnit
http://www.nunit.org/
http://sourceforge.net/projects/nunit/

Extreme Programming
http://www.extremeprogramming.org/rules/testfirst.html
http://www.extremeprogramming.org/index.html

Refactoring
http://www.refactoring.com

Agile Modelling
http://www.agilemodeling.com/