Extreme beginnings

You should be doing XP (probably). But how do you start doing XP?

You should be doing XP (probably). But how do you start doing XP?

Assuming that you have convinced all the stakeholders to try it, the answer isn’t that difficult – get a coach. I should declare my interest in this: I make my living as a freelance coach and Java architect, but I’m not just touting for work here. The answer happens to be accurate, but I don’t want to be seen as one of those consultants who tells you that everything you’re doing is wrong and the only way to fix it is to buy my new miracle cure. The most quoted reason for failure on a new XP project is lack of experience with the process. The most common comment is, I wish that we’d hired an experienced coach.

Okay, now you have your coach, what’s next? The sweetest introduction would be on a green-field project, with about six developers and an on-site customer. If you can arrange this, with an experienced coach, then you’ll significantly increase your chances of success. Unfortunately, this is just a dream for a lot of companies, so what can they do?

Start slowly, introducing the practices one by one. Instant benefits can be found from pair-programming -- which will double the productivity of an individual programmer and massively increase the quality of the product. So you’ll finish each task at least twice as fast as estimated, and it’ll be of considerably higher internal and external quality. These figures are facts by the way, not speculation or guesses, backed by sound academic research and industrial analysis. You should ask yourself what the basis is for your current practice of developing solo; it’s unlikely to be based on reason.

With pair-programming comes the benefits of collective code ownership. This gets rid of a lot of the communication issues relating to programmers. Fred Brooks [author of No Silver Bullet, said to be one of the classics of software engineering] would have loved it.

Okay, now you can move to continuous integration. Just start building your software every day. It’s not really that hard, and as you practice it’ll become easier. You’ll quickly notice that it’s considerably easier to do it every day than once a month.

The next thing to do, in most companies, is introduce unit testing. In XP we develop our code test first. We write a test, and when we’ve seen it fail we have an excuse to write some production code. This cycle is repeated one small test at a time.

Surely nobody could argue against writing unit tests. Isn’t all of our code meant to be tested? If you answer no to this then you’re probably guilty of sending untested products into production. You should be shot.

Introducing this practice on a legacy, or other non-green-field project can be difficult, so do it one task at a time. Whenever you need to write code, add the tests in first. If it’s part of an existing class or module, write some tests that test its current behaviour.

Then when you make a change you can immediately discover if you’ve broken anything. Do this step by step and over a period of time you will have organically grown a unit-test harness for your application.

Once you’ve introduced unit tests you can get on to refactoring. Refactoring is very important, so it’d be good if you did it. Whenever you’re working on a module or class, and you’ve finished implementing the tests, you can do a little refactoring. We use a technique called “low hanging fruit first” – where we look for the easiest thing to refactor and do it, then choose the next easiest. Eventually we find that the difficult stuff has been so simplified by the earlier refactorings, that it is no longer difficult.

If you’ve got pair-programming, unit tests, refactoring, continuous integration and collective ownership, you’ve got most of XP already, without breaking a sweat. Now comes the harder stuff.

The next few practices require changes in the company’s culture and project management methods. Up until now you’ve just changed the way the programmers work – and that isn’t too difficult because programmers are rational.

Up until now you’ve been writing your software as well as is possible, but you still haven’t been able to plan and control it accurately, nor ensure that you’re providing the highest match to the customer’s real needs.

The planning game and on-site customer take care of these issues, but they’re really difficult to do – not technically, in theory and practice they’re very simple -- but culturally and socially it’s hard. How do you get your customer to commit to assigning a member of staff full time to a project? Of course, if the project is valuable enough to the client then this shouldn’t be a problem, it’s just part of the expense, and if it’s not valuable enough you should be questioning the client’s need for the software at all.

Dollery is a Wellington IT consultant. Send letters for publication in Computerworld to Computerworld Letters.

Join the newsletter!

Error: Please check your email address.

Tags extreme programming

More about Fred

Show Comments