Early on in the talk David described how they needed to make a decision about whether to rewrite the system from scratch or build on top of the current one and strategically rewrite parts of it. The latter option was the chosen one and others seem to be in agreement that this is the best way to approach the problem. The argument for doing this that I’ve often heard is that you end up playing catch up with the old system and eventually end up in the situation where you need to re-write the re-write but in this case David suggested that re-writing the whole system was not an option for the business.

David described the early trainline approach to development where it sounded like the main goal was to get features out to market as quickly as possible. He spoke about the 'first mover advantage' whereby if you’re the only product available to customers then the quality of your offering isn’t the most important aspect since you are the only option. James Shore describes this as 'voluntary technical debt' and I think we need to at least consider whether it’s more important to get quick feedback on our work by getting it into production quickly and perhaps taking some shortcuts along the way. David was quick to point out that at some stage you do need to address that technical debt otherwise you’ll end up in a world of pain. I’m not sure how exactly you know where to draw the line with respect to this because it would be very easy to just get into a hacking culture until you get to the stage where it’s almost impossible to add any new features to the code base.

A bit of time was spent talking about various metrics which were used including looking at the cost per story point delivered. They didn’t go into further detail on that but it seems like it’s the dangerous area of metrics which are easy to game that Dan North talks about in his 'Our obsession with efficiency' presentation. I’ve not really come across a good low level metric which allows you to accurately tell how well a team is doing. The best measure seems to be just looking at whether a team is consistently delivering valuable features to their users. That’s often considered a bit wishy washy so it’d be interesting to know if anyone has a better way to measure performance that works well.

They both spoke of the need to ensure effective communication between 13 teams operating across 3 different locations (Bangalore, Pune and London) and suggested that rotating people and making extensive use of video conferencing allowed this to be achieved. The rotation included having subject matter experts from thetrainline.com going to India and working with the teams and David suggested that you still need to have a big commitment to a project if you want it to be successful even if it is being done offshore.

In his summary David emphasised the importance of releasing frequently into production. In a lot of organisations releasing into production ends up becoming a big deal and so it happens less and less frequently but David suggested that thetrainline.com are releasing new features every 6 weeks and are aiming to get that down to every fortnight. I guess the ultimate is to have continuous delivery as described by Timothy Fitz in his blog post.