This Bamboo customer story is the second of an 8-part blog series about why so many developers adopt continuous integration, written by John Ferguson Smart.
John is a consultant and trainer specialising in Build Automation, Enterprise Java, Web Development, and Open Source technologies, currently based in Wellington, New Zealand.
Aligning work habits
Claudia and Hans work together on a development team in Frankfurt writing internal web applications for a large multi-national. While they were working on the same module, their work habits varied dramatically. Getting aligned on how they do their work was critical from transforming from a mediocre team to a high octane development team.
Claudia adopted the habit of developing in small units of work, ensuring that they are fully working within their limited scope, and committing her changes. She began using a ‘Test-Driven Development‘ development approach, so the code changes she makes are always accompanied by a set of new or updated test cases. Before committing her changes, she would integrate any changes that have been made by other developers since her last commit. Since she commits her changes several times a day, this integration work is usually limited to a small number of changes, and if there is a conflict, it is not difficult to figure out who made the change, and to discuss the conflict with them if required.
Hans, on the other hand, was working as a solitary developer, who preferred to work on his latest brilliantly-designed feature in isolation, for several days or weeks, until it was as complete as possible. When Hans finally integrated his changes, he would have to integrate all of his changes with weeks worth 
of updates from other team members – a sizeable task indeed. It was also an inefficient one, as any integration issues that were discovered were late on in the piece, and required major rework on the part of both Hans and the other developers. For example, over the last week, Claudia had made some significant changes to a core database access module that Hans happened to need for his new feature. Now Hans also updated this feature on his side, but in a totally incompatible way. Someone would have to rethink their solution, and since several other developers were already using Claudia’s implementation, chances are it will be Hans.
Diagnosing the root cause
This is very much a problem of communication, rather than a technical one. If Hans had been aware of the changes that Claudia was making to the database access module, he could have taken this into account for his own changes. Since Claudia was committing regularly, all Hans really needed to do was to synchronize his code changes with the source code repository on a more regular basis. Once developers have learnt to write in small, well-tested units and commit their changes often, you need to ensure that everyone who needs to know about code changes is informed.
Making the switch to Continuous Integration
After implementing Bamboo, Hans began to get notifications every time Claudia commits some changes. Seeing the benefit, he quickly figured that it is in his interest to commit working changes as frequently as often and integrating his brilliant code with the rest of the team’s was no longer a hassle. The whole team began to feel that they were coding more and refactoring less. The fast, relevant feedback on build failures helped each developer from getting blocked by a broken build. Once Hans began using Bamboo, he began to realize his build errors within minutes.
Last time we talked about Johan’s outsourcing blues; stay tuned for the next Bamboo customer story when we talk about lightning fast notification.
What’s your adoption story? Tweet Atlassian or leave a comment below about how and why you adopted CI.