Getting Started

Adrian Sutton

So we’ve got a huge chunk of legacy code (making up 3 main products and a lot of integration products around them), automated builds after every check-in and a bunch of tests that are somewhere between unit tests and integration tests and a team of developers who haven’t had any significant experience with XP (excepting our new hire, Doug South, who’s to blame for the XP idea in the first place). Did I mention tight deadlines and ferocious competition? We don’t have time for down-time, we need to get this process up and running and quickly and smoothly as possible.

Where to start?

I think it will pay off that we started by bringing the engineering team together to discuss XP and see if it was a direction we wanted to go in as a team.  XP, like anything else, can’t work if it’s forced on people by management. So with the team on-board, which facets of XP do we focus on getting going first?

Well with a new hire that has experience with XP and no knowledge of our codebase or of the surprisingly specialist field of WYSIWYG editing, pair programming seemed like a good idea so we’re trying that. We’ve also got one of the most technically challenging features we’ve ever attempted to do which has huge potential to destabilize the codebase – test driven development also seems like a good plan. Since we already had some continuous integration happening, we decided we should also start getting some reports out of it and making use of them so continuous integration made up the third item on our XP hit-list.

The aim would be:

  • Pair Programming
    • Pair whenever possible given the small number of engineers and the large number of products we develop.
  • Test Driven Development
    • We already had the policy that all new code must have unit tests.
    • Now tests should be written before writing the new code.
    • A training afternoon was planned to teach the team how to do TDD and books were ordered.
  • Continuous Integration
    • Builds were already up and running after each check-in but currently only gives a pass or fail message and a brief (sometimes incomprehensible) reason.
    • Modify the build process to publish reports on test success/failure, code coverage, coding standard compliance (we already have one and are pretty good at following it) and whatever else we come up with that could be useful.
      • It’s important not to drown the team in reports but at the same time, we’ve not seriously looked at many of the reports that can be generated from a codebase and so we need to try them out and see if they provide any useful insights into project status. We’ll need to continuously review the reports we generate to decide if they have value and get rid of those that just distract us.