Let’s get the punch-line out of the way up-front: “Without being asked”. In a move that genuinely surprised me, the team behind the Atlassian ordering system adopted peer code reviews in a purely organic manner. I’ve been thinking about why this is…
But don’t developers hate code reviews?
Code reviews have a long and chequered history in software development. I’m not exactly a grey-beard, more sort-of “salt-and-pepper unshaven”, but I’m old enough to have been part of a waterfall software development project for a military contractor. And I can assure you, the horror-stories about overrun projects and death-marches are entirely true.
One of the techniques that was used in the early days of that project was the Fagan Inspection technique. Although far more formal than anything you’re likely to see in modern software projects (it goes as far as to specify a seating plan for the code review meetings), it was nonetheless revolutionary at the time, and was the first to quantitatively prove the value of up-front human oversight of code. These inspections were mandated by management, and largely regarded as an inconvenience by the developers, although objectively we knew their value. Unfortunately, once the wild inaccuracies in the project schedule came to light code reviews were the first casualty, and no-one was sad to see them go.
Later on when I came to again work on a military project I insisted on adopting the then-prototypical “extreme programming” (AKA “agile”) methodology of incremental development and testing. But even then we didn’t do regular code reviews: here just never seemed to be the time, and no-one loves having their code picked apart.
More recently I’ve be attending a lot of conferences, and in discussions with other attendees similar stories tend to come up. But nowadays I have a different story to tell…
About that order system
I’ve written about our Hosted Account Management System (“HAMS”) ordering platform before; while I’m probably not able to discuss the actual numbers, suffice it to say that hundreds of millions of dollars of orders, refunds, and other transactions have passed through it in its lifetime. I’ve also talked about our trials and tribulations attempting to make Subversion scale at a global company. The nature of development in a Subversion environment meant that even on a critial piece of software such as HAMS, code reviews were infrequent and generally reserved for new functionality.
However, in 2011 we finally migrated our code base to the newly-supported Bitbucket git repositories. And something interesting happened: we started to perform code reviews on every change–not just those deemed unusual or critical. Of course, these code-reviews were far more lightweight than the previous methods, and we called them “pull requests”. But they were still code reviews. We did this organically, with no mandate from higher-ups and no internal discussion. It just happened.
So what changed?
Looking back on this, I can see number of reasons for why this occurred. Partly this is due to the relative ease of branching and pull-requests in git workflows, but something deeper was going on. This was after major changes of the HAMS 3.0 rewrite, and HAMS was no longer an architecture that one person could understand fully. The team started to self-organise into subject-matter experts, each of adopting our areas of strengths. At the same time, our team was starting to add new members. Additionally, Atlassian was also expanding, and we were all aware that mistakes on our part could cost the company dearly.
Pull requests allowed us to share and mitigate the risks associated with each change to our code base. But it also gave us a personal piece of mind that allowed us to keep sleeping at night when dealing with areas we were not so comfortable with.
I particularly remember a case where I was modifying a core area of business logic for a pricing structure change (my self-appointed role on the team was “the technology guy”, not least because I suck at the business-logic side). The further I got into the change the more uncomfortable I became, and my usual technique of “test it ’til it bleeds” wasn’t helping–it doesn’t matter how good your testing is if your basic logic is wrong! But when it came time to merge the change, I immediately added Alison and Ernest to the reviewer list, both of whom have a preternatural talent for squirrely business problems. Once they started poking around my logic and asking questions, I felt a lot better.
Of course, shared responsibility is not the same as abdicated responsibility. My code is still my baby and I have the responsibility to make sure it grows up strong. I’m just not a smothering mother anymore.
The post Organic code reviews for a billion-dollar order system appeared first on Atlassian Blogs.