OH
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 (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.
Today
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…
