agile-manifesto-the-answer-small.pngAt Atlassian we believe in “agile” development (similarity to a very popular buzzword recently unintended). We strive to be as agile as possible and clearly see the benefits.
Sure, there are teams who are “more agile”, there are teams who are less. Almost every team applies different agile practices. That’s OK as we believe in self-organisation and bottom-up evolution. Still we all believe in the 4 fundamental principles of agile philosophy, which are compatible with our company values.
When Crucible became part of the Atlassian suite, a lot of us wondered how code review would match our agile environment. Two years later, code review has become an integral part of our agile developers’ day-to-day jobs. Some say they are addicted to it. Let me tell you why.
I am not going to elaborate on an obvious advantage of code review: improved code quality. Instead, I would say that code quality is a nice side effect, but not the purpose of code review in our teams.
Code review is one tangible way that we enact the first principle of the Agile Manifesto: “Individuals and interactions over processes and tools”. Here are some examples of how code review helps us collaborate better:

New team members

tutor-child-small.jpgAtlassian is constantly growing. We hire passionate, often quite- experienced developers who need to dive into our non-trivial code base very quickly. In addition to new hires, existing team members sometimes rotate to different temporary or permanent positions.
Code review makes ramping up on a new code base faster and less painful, and helps maintain engineering knowledge across the team and the company over time. People more experienced in the code base review newbies’ commits (there’s no better way to learn the product than to start coding bugs or stories), and then advise them on which design inconsistencies they introduced and which shared components or utilities they should use and how. In return, the newbies can bring invaluable experience, good engineering practices, useful libraries, nice patterns, tricks, etc. from their former teams, resulting in fresh insights to improve the code base. In short, code review is a two-way conversation. Both the author and reviewers communicate and learn from each other.
Code review is even more important when a really junior developer joins a team. Senior developer don’t have time to hand-hold the junior folks, since they need to be coding. That said, doing small but frequent code reviews of the junior developer’s code is no big deal. The result? Senior developers can focus on writing code for most of the day and spend a 10-15 minutes a couple times per day to review the code changes by junior developers. The junior developers benefit from feedback, and the senior developers haven’t lost valuable coding time.

Geographical distribution

Atlassian develops software on 3 continents, in time zones which differ by as much as 10 hours. Most teams working on a given code base are co-located (it really helps), but sometimes it’s just not practical or feasible. Thus we ended up with a few geographically distributed teams – a big problem for some agile practices such as pair programming and daily stand ups.
Tools-supported code review comes to the rescue here by encouraging and facilitating knowledge flow between different locations.
With asynchronous code reviews, time zone differences can actually be an advantage. We often raise a review in the afternoon (as a good summary of our day’s work), ask for review by colleagues across the ocean and go home. When we arrive at work the next morning, we have their review feedback: they were working on it while we were asleep! First thing in the day, we can answer questions and fix identified problems, and then proceed with our daily development tasks.


Code bases do not live in isolation. Most of Atlassian’s products integrate with each other in some way or another.
For example, I work on IDE Connectors, which need to talk to Atlassian server products via remote APIs. These APIs are continuously evolving, often in response to the needs of the IDE Connector team. The server product teams are mostly located in Sydney, and their work day is ending just as ours is beginning.
Code review is the main way for the IDE Connector team to provide feedback about the remote APIs we rely on. Whenever there is a change related to a remote API, I am one of the reviewers – thus I can learn what is going on on the server side, constructively criticise the evolution of the API, and ensure that my teams interests are at least heard if not fulfilled.
A similar situation arises when you need to program something in the product you normally don’t work on. I call it “guest programming” – e.g. you need to add some missing API or plugin point or just fix a problem which is only reproducible in your environment.
Code review enables guest programming by increasing courage of both sides. The team which owns the product is less reluctant to let an outside person touch their code base, and the guest programmer has more courage because other folks will review his code to prevent any nasty bugs.
Talking about courage – some of us actually feel anxious when deprived of code review. Unit tests establish a safety net which helps you be courageous to mercilessly refactor and improve the code while avoiding nasty regressions. Similarly, code review is another safety net, which gives you this feeling that your crazy ideas will be evaluated by others before they will go to production, and that your great design, utilities or tricks have a chance to be spotted and reused in other places by other team member. This is a real teamwork!
Code review may be difficult and costly to implement and sustain. Not every team or team member wants to do pair programming, and code review meetings can be too time-consuming. Obviously we use Crucible, which handles the logistics of a review and lets developers concentrate on the most valuable part of code review: thinking about the code and providing feedback.
In the next instalment I’ll share a few pieces of advice and precautions related to implementing code review in an agile team or company as a standard process.
In the third and last instalment I would like to compare pair programming with code review and reveal a few rules around code review that evolved at Atlassian.
Have an opinion or question? Drop us a comment below!

“Lesson” photo courtesy of eddidit / CC BY 2.0
“Obelisk” photo courtesy of Kevin Dooley / CC BY 2.0

Code Review in Agile Teams – part I