Mark Needham

Thoughts on Software Development

Book Club: An agile approach to a legacy system (Chris Stevenson and Andy Pols)

with 2 comments

Our latest book club session was a discussion on a paper written by my colleague Chris Stevenson and Andy Pols titled ‘An Agile Approach to a Legacy System‘ which I think was written in 2004. This paper was suggested by Dave Cameron.

These are some of my thoughts and our discussion of the paper:

  • The first thing that was quite interesting was that the authors pointed out that if you just try and rewrite a part of a legacy system you are actually just writing legacy code yourself – we weren’t sure exactly what was meant by this since for me at least the definition of legacy code is ‘code which we are scared to change [because it has no tests]’ but presumably the new code did have tests so it wasn’t legacy in this sense. Rewriting the code doesn’t really add any value to the business though as they point out since all that code might not even being used in which case it is just wasted effort. The idea of not rewriting is something that Uncle Bob advocates and Eric Evans also mentions the dangers of trying to replace legacy systems in his latest presentations.
  • I thought it was interesting that the team didn’t make use of automatic integration since they were frequently integrating on their own machines – I’m not sure how well this would work on a big team but certainly if you have a team of people fairly experienced with CI then I can imagine that it would work really well. Dean has written a post about serverless CI which covers the idea in more details.
  • I liked the idea of putting up politics as user requirements on the story wall and then prioritising them just like any other requirement. More often the approach tends to be to try and address these problems as soon as they arise and then end up not really solving them and then getting burnt later on. This approach sounds much better.
  • Another idea that I like is that the team didn’t get hung up on process – the teams I’ve been on which worked the best weren’t slaves to process and I’ve often heard it suggested that having a process is just a way of dealing with the fact that there is a lack of trust in the team. Jay Fields recently wrote about the idea of having more trust and less card wall and Ron Jeffries has a recent post where he talks about the light weight way that we should be making use of stories.
  • Another really cool idea which I don’t remember seeing before is having the whole team involved in major refactorings until the whole refactoring has been completed. Quite often with refactorings like this one pair might go off and do it and then when they checkin later there are a lot of changes and the other pairs have trouble merging and now have a lot of code which they are unfamiliar with.
  • The idea of having a self selected team sounds like an interesting idea as you then only have people on the team who actually want to be on it and want to make things happen. I’m not sure how often this would actually happen but it is a nice idea.
  • The importance of testing the system against a live database before putting it into production is emphasised and this goes beyond just using production data in a test environment. The team also made use of data verification testing to ensure that the new system and the current ones were working identically.

Although this paper is relatively short it’s probably been the most interesting one that we’ve looked at so far. I think a lot of the ideas outlined can be used in any project and not just when dealing with legacy systems – definitely worth reading.

Be Sociable, Share!

Written by Mark Needham

July 15th, 2009 at 12:53 am

Posted in Book Club

Tagged with ,

  • Hi Mark, thanks for reading our paper! To try and answer your question about why the rewrite was just writing legacy code (even though the rewrite had lots of tests):

    Due to the nature of the stored procedures (possibly triggered by external events unknown to us at the time – the parallel running was a voyage of discovery) it was difficult to specify the correct behaviour in a test. Just because it did something today did not imply the same was true tomorrow. So we did not have the usual test safety net.

    It was also taking a huge amount of time and energy and not delivering anything new (the business already had the same functionality in the original system)

    Hope that makes sense?

  • Hi Andy,

    Cool that makes sense – thanks for clarifying.

    Really interesting paper though, we enjoyed reading it.