We don’t have time for code reviews


If you’re a developer since some years, you probably have heard several or all of those explanations:

  • “We would love to do code reviews, but we have a very tight schedule”
  • “Quality matters to us, but we just can’t use a developer just to check the work of another”
  • “Let’s remove the code review session of this afternoon – we need to finish our sprint stories first”

Or any other form resolving to:

“We don’t have time for code reviews. We would love to, but we can’t. We think it is tremendously useful, it is regretfully just not possible.”

My secret

I have a secret: we don’t have time for code reviews either – heck, we don’t even have a task for that in GitHub.

And still, we do code reviews. Actually, we review every single piece of code.

Code review is not a task

Code Review

Code Review (Photo credit: owenstache)

Let’s speak about something else. Some years ago, I was working in a development team at a big company, first as a developer, then as a team leader. We started doing Unit Testing at some point, and it quickly became “good practice/mandatory” in our team (I think good practices need to be applied by everyone in a team, requiring some kind of “collective enforcement”). When I reported to my manager about what was done or still in progress, I never talked about Unit Tests.

Why? Because Unit Testing was no separate task. It was just part of a given feature or bug fix. The same way I did not have tasks for “commit” or “documentation”. This sort of avoided the whole “do we have time for Unit Tests debate”.

Unit Testing was not a task there – it was just a (mandatory) part of a development task.

Definition of Done

This is actually depends on something very important and often overlooked in a team (even an agile one): a common Definition of Done. When can you move this post-it from “In Progress” to “Done”? What does it means? In my previous team, it meant that the code was written and tested (using Unit Testing). If the Unit Test is not written, it is Not Done. Quite easy.


We don’t have tasks for Unit Testing at 8th color either, and you could read our whole issue list without seeing something like “Code Review” – because again, Code Review is not a separate task. It is a part of a given User Story (feature or fix).

Actually, I lied: you can see them in GitHub – as Pull Requests. When you think about it, a Pull Request is just a state that says that a given issue is “ready for review”. Yet representing this simpled step has proven quite effective in matching the code review workflow.

And by the way: By doing code reviews (first using automated using our own PullReview, then by asking a colleague), I think we are actually winning time…

Enhanced by Zemanta

8 thoughts on “We don’t have time for code reviews

    1. Martin Post author

      Hi Ryan,
      Sorry for the late answer – Akismet did put your comment in our spam folder. That was obviously a typo (someone else pointed it to me, so fixed in the article), but I agree on the irony there.

      Maybe we should review everything single piece of post, too.


  1. Pingback: We don’t have time for code reviews | Enjoying The Moment

  2. pat price

    Having gone through the first project from hell working on the OS for the first space shuttle (1972-1974) management drove us to put in hours (12 – 16 hour days for two years) and then the second project from hell as an engineering manager it became obvious that I had to just lie to my management so that we could do actual design and unit testing. What is sad but true is that engineers seem to drink the management Kool Aid as they move up the so called ladder. One of my men/women on the team printed out a banner for our bull pen that said, “There’s never enough time to do it right but there is always time to do it over” otherwise known as the Tao of programming.

    1. Martin Post author

      Hi Pat,
      Quite a story there! You worked on the >Space Shuttle< OS ?. Did you wrote about the experience? I would love to know more.

      I agree on the sad but true reality: I see developers saying those same excuses, and they should know better. Looks like most of us are actually ready to put stupid (even if often well-paid) hours than to stand up for what we believe is “a good practice”.

      And even if I made my IT carreer being transparent (= telling mostl if what I think mostly the same way to mostly everyone – customers/peers/team members/bosses), I always thought that good relationships with managements does not means telling them everyhing and spamming them with all details. The Definition of Done could quite easily fall into the team hands, without requiring to lie.


    1. Martin Post author

      Great idea. And we could meet together to look at our code and discuss it.

      Joke aside, best way to do them is to bring them inside your development workflow. Else you’ll always have something more urgent to do.


  3. Pingback: Noticias 30-10-2013 - La Web de Programación

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>