--- title: XP and the cost of change url: https://www.grahambrooks.com/post/2010-02-01-xp-and-the-cost-of-change/ date: 2010-02-01T00:00:00+00:00 author: Graham Brooks tags: - Agile - Testing --- # XP and the cost of change I have found myself drawing the classic cost of change graph a few times recently so thought I would blog about it. The graph was popular a few year ago in explaining the differences between and eXtream Programming (XP) team cost and a waterfall team cost. XP Wall Graph.png The important thing to remember in interpreting the graph is that the lifetime of a software system is typically far longer than the initial development. Most systems spend much longer in ‘maintenance’ than they ever did in ‘development’ so anything that can be done to make maintenance (ongoing development) more effective has to make sense. The XP premies is that by augmenting the codebase with automated tests changes are easier to make later on. Developers can regression test the code to make sure that they have not broken anything and that their new tests also pass. This requires the same if not more discipline than the original development. It is also important that refactoring be part of this ‘maintenance development’ without it the system will degrade, making it more difficult to effect changes. A couple of years ago I was fortunate to work with a team developing a web application. Nothing special perhaps but the combination of background and skills for this project turned out to rather special. After the first release which was made under extreme time pressures new features were needed and added. The key difference was the aggressive and determined pursuit of simple elegant code present in all of the team. At around the second release it was felt that ‘the code just wrote itself’. The code seemed to support the addition of new features and productivity improved dramatically. Some time later it was decided that ongoing development be moved offshore. As a lead developer this can be a troubling time but as part of the handover myself and another senior developer were asked to take the project offshore to ensure a smooth transition. And this is where things got interesting. The team were delighted with the code and were keen to get started. Some scheduling conflicts meant that they could do a development iteration (1 week) and work on some of the backlog before envisioning the next major release. That week was great fun with many whiteboard discussions about the principles underlying the architecture and the design. After the development iteration the team felt confident in moving forward. That confidence proved to be true. The rate of changed increased and the client was delighted with the results. If you are reading this and were part of the onshore or offshore team then thank you for such a fun time and wonderful code. P.S. And yes I remember how hard the project was too.