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.