Case study: Upsource in Miquido

Maria Khalusova

Upsource helps us make our mobile apps awesome

My name is Radoslaw Holewa and I am a co-founder and CTO of Miquido, a mobile app development company that delivers successful business-driven mobile solutions to clients like Skyscanner, Aviva, HelloFresh, Nestle and many others. Today I will give you a quick overview of our code review process and the reasons it’s crucial for Miquido development.

It is a well-known fact that code reviews help improve code quality which results in delivering high-quality software. It is not so obvious, though, that code reviews speed up the spreading of knowledge across a software development company. Today I will share our experience in using Upsource for code reviews at Miquido, which has turned out to not only improve quality but also changed the learning curve of our developers.

The approach

First of all, let me give you some background and describe our approach. Every project we run at Miquido follows a Scrum-based software development process, with JetBrains tools at its core. We have two-week-long sprints, daily stand-ups, demo sessions, nightly builds for client feedback, etc. Of course, we also have daily code reviews. Code review is done in the morning, every single working day, as one of the first tasks that developers perform when they come to work (just after grabbing some coffee and reading emails).

It usually takes about 10-20 minutes to review yesterday’s changes. We use git and git-flow workflow, so our developers mainly review changes done in feature branches before they get merged. It is a post-commit approach. Why, you might ask? More on this later in this blog post.

Fewer bugs in code mean smoother projects

First, the obvious thing. Since introducing code reviews, we feel projects with code review in place perform way smoother than those without. It is not so easy to compare different projects as there might be various difficulties in each of them. It is also hard to find the right metrics for code review effectiveness. Still, the overall impression is that projects done with code review have a more painless ending phase, without too much time spent on testing and bug-fixing.

Naturally, it doesn’t mean those projects are bug-free. It mainly means there are fewer trivial bugs that could be very often discovered at first glance, letting us avoid the ping-pong game between testers and developers. That translates into less overhead on testers to test and report bugs, less overhead on PMs to manage issues, and finally, less overhead on developers spending time on fixing bugs.

That was the obvious part, but for me it is not the main aim and benefit of code review.

Learning curve has drastically changed

We are seeing developers at Miquido evolving much faster. It is especially visible in case of junior developers. Instead of reinforcing bad practices they might have learned without code review, we educate them straight in their code, so they quickly learn what the good practices are and how to use them.

This gives a huge boost to building a highly skilled team, especially when it’s so hard to hire good developers.

Project-wide knowledge spread across team

A module is worked on by a single developer in your team for over two months, then he or she goes on vacation, and suddenly someone finds a critical bug in that part of the app. Nobody knows what’s going on in this code. Sound familiar?

Code reviews prevent situations like that, by spreading the knowledge about your project across the whole team. At Miquido, every developer’s code gets reviewed by a different team member each day. In this way, all team members know enough to dive into others’ code in case of an emergency.

Code review increases motivation

Motivation has a huge impact on the way we do our work. Everyone wants to work on something awesome, something done “the right way”. It’s no secret that a project with “bad code” can be demotivating; it’s also nothing uncommon for developers to change jobs because of “disaster” projects.

Code review is our way to increase motivation: both the motivation to stick to best practices and the motivation for day-to-day work by making projects a pleasure to work on. No spaghetti or boilerplate code, no painful changes.

“I have no time for code review!” O rly?

Just like unit tests, some people’s excuse for not doing code reviews is that they’re on a tight deadline and have no time to do it. Well, I don’t buy that.

In my opinion, the improved learning curve (better skilled developers), project knowledge spread across the team (reduced risk), and increased motivation (lower retention rate) are reasons enough to perform code reviews. Add higher project quality to it (easier to introduce changes), and the verdict is clear. Spending about 5% of project timeline on code reviews is definitely worth it.

Measuring the effectiveness of code reviews

It is difficult to measure project code review effectiveness as there are different factors having impact on how successful a project can be. One of the measurements you can do is the number of reported bugs during code review. This number can naturally differ between projects and will decline as the team gets more and more experienced (or more used to the best practices).

Measuring motivation can mainly be done via direct conversations with developers. We notice that those who participate in projects where code review is part of the process really appreciate it and see its advantages.

Pre- or post- commit reviews?

Each of them has its pros and cons. Pre-commit code review is about forcing developers to stick to the approach. Personally, I think it is better to create habits than to exert pressure, which is why I prefer post-commit reviews.

Of course, that has its own downside: there is no guarantee that each commit will be reviewed, so in theory, quality might be lower than for pre-commit review flow. On the other hand, those pre-commit rules can be too strict and for example block from releasing test version, especially when reviewers are not available.

As you can guess, at Miquido we go for the post-commit approach and build a habit, a culture of responsibility for projects where people tend to take care of project code quality. And this is where Upsource helps us.

Why Upsource?

The first time I saw Upsource, it was a pre-1.0 version but already impressed me. After some time, I had to find a code review tool for Miquido, so I compared it to other existing solutions (both commercial and open source).

There are many code review tools on the market, from really simple ones like Bitbucket code review feature (we use bitbucket git repositories at Miquido) or Codebrag, to feature-rich ones like Crucible or Gerrit.

After a comparison of different tools, I came to the conclusion that Upsource was the way to go because of these advantages I found important:

• On-site hosting. I installed it on our in-office server, and it was way faster that all those in-the-cloud tools.
• It provided Java inspections out of the box (now also PHP, JavaScript and Kotlin – I can’t wait for Swift and Obj-C), which was yet another level of quality control.
• Had great code navigation, which is even better now!
• It had a plugin for JetBrains IDEs (we use IntelliJ, AppCode and PhpStorm/WebStorm), so it was even easier to review code, no need to leave your IDE!
• Very good search feature.
• Its user interface was simple, yet beautiful (comparing to other tools – this is obviously relative). To me it looked like the code review tool with the best UX (personally I really don’t like Gerrit’s UI).
• It was possible to integrate with other JetBrains tools and create a real ecosystem of cooperating tools.
• At that time it was quite cheap (the price is now higher but it has many more features than in version 1.0), cheap enough that I could buy it instead of going for one of open source tools.

Despite the pros listed above, there are still a few things missing that I am waiting for:

• Swift and Obj-C support (we are a mobile app development company and iOS app development is a large part of our services).
• More valuable code review analytics (with over 50 projects configured it is hard to track overall code review performance).
• Support for Bitbucket pull requests (only GitHub is currently supported).

Upsource is not a totally perfect tool. Especially if you are a fan of pre-commit code reviews, it is not a tool for you. But if you prefer the post-commit approach like I do, then in my personal opinion it is one of the best code review tools available out there, and when used in the right way it can give you and your team a huge quality and knowledge expansion boost.