One of our company’s OKR for 2015 was to improve our Customer’s Satisfaction by X%. For the Engineering department this meant that we needed to improve the way we build software and the engineering practices and processes behind it so that by the end of the day the quality of the software that was shipped to our different clients was better.

So we started to enforce (we were doing it before but not in every team) TDD and CI throughout all development teams in the company and the outcome has been very positive.  We have automated tests that we did not have before and we can detect issues on a daily basis. Moreover, our software engineers now are more keen to implement unit tests because they see the value that it brings to the different projects they work on.

Even though we took a big step with TDD and CI towards our code quality goal, we knew we had to do more. We are 100% Agile and we run our business (from Sales to Development) using Scrum.  In the development side during our Sprint Planning we started to encourage the Pair Programming development technique  especially for complex stories. We noticed the stories that were implemented with a peer (below is the image of two of our brigthest Software Engineers Franklin Buitron and Daniel Coellar pair programming) had less bugs which reflects quality improvement, they were finished faster, and the knowledge of the functionality was spread as a result.

Pair programming was our second step towards improving software quality but we knew we had to do more. Many tech companies with high quality software were talking about how Code Review helped them to reach that level so we decided to pay more attention to it and adopt it in our development processes. Moreover, if  genius computer programmers such as Guido Van Rossum , Ken Thompson and Linus Torvalds check-in their code for Code Review why not us “tangocoders”?

In the beginning we started to add a Code Review session as part of each Sprint where the dev team would review each other’s code. The result was disappointing  because the sessions were time consuming.  We would not be able to review all the code and more importantly sometimes the code improvements detected were too late. Changing the code then, would take a considerable amount of time so we would always put it off therefore our technical debt was always increasing. We knew there had to be a better way to do this.

Reading about how Facebook ships code to their web application twice a day everyday blew our minds because we knew they had to have a way to guarantee that the code shipped did not have bugs. We learned that one of the tools they use and open sourced was Phabricator. We looked into the Differential Application tool for Code Review. The concept was simple, a developer works on a development branch implementing a feature, once they are done they commit the “DIFF” and select a reviewer of the code. The reviewer will get an email from Phabricator so he can review the code, if the reviewer approves the code, then the developer can check-in the code to the master branch.  If the reviewer requires changes, then the developer has to make those changes and send the DIFF again. So basically NO code makes it to the master branch unless a reviewer approves it.

We decided to use Phabricator in one development team.  In the beginning people were skeptical saying that it would take a long time for a person to review code and we would deliver less stories per Sprint because we have to allocate time to review the code. After using Phabricator for about two months we realized that the time it takes for someone to review code is insignificant compared to all the benefits we gained such as:

  • Finding bugs and improvements: During this period we have found bugs that would not be detectable by an automatic test. We also found better ways to implement features so our technical debt was reduced on a daily basis.
  • Consistent Style: We have code guidelines and best practices that before were inconsistently used.  Now that we are using Phabricator we have had 100% consistency with using the code guidelines and best practices.  People tend to deliver better code when they know somebody else will review it.
  • Mentoring: The more you learn to read other people’s code, the more able you are to invent your own in the future.
  • Collective Knowledge: Since team members review other team members code, they will know just by reviewing the code what the feature is about so at any moment they can go ahead and change the code when needed because the knowledge is with the team and not the individual.

Phabricator has really changed the way we work and we truly believe that it was the breaking point toward reaching our ultimate goal which is to improve our software quality.

Give Phabricator a go for your development teams!