Continuous Code Review
by
| Not getting the most out of code reviews? We can fix that and add a whole lot more fun into the process… |
Code Reviews should be fun, they should be interactive and they should happen as part of the design as well as the implementation.
It’s waste to wait till someone’s done and dusted before reviewing the code (only to think there was a much easier way to do some of those things that would have meant much less code to maintain). But by then the horse has bolted and it’s too late to change or even broach some of the other paths they could have taken - they’re going to defend their approach to the hilt - its human nature.
Continuous code reviews
Sit down and review with the coder as he’s writing the tests, bounce ideas off of each other and get to a simpler design and implementation because of that - something that neither of you would have got to individually. I believe this way of doing a continuous code review is also known as ‘pair programming’.
Efficiency
Wait, ‘pair programming’ - we don’t want to do that - we don’t have the staff or time to do that. Or do we? If you’re not pairing there’s a significant amount of meetings going on trying to juggle the additional work in progress (WIP) because everyone’s doing twice as much stuff at once. By swarming and focusing on getting things done (DoD) with pairing we’re reducing the work in progress and reducing the cycle time of items getting done. Count the total hours of meetings you’ve got coming up in the next week and tell me there’s not room for some pairing.
And anyway, where does all that time go when you’re coding? Is it 100% bashing out code? Rarely, your coding day is a long line of blockers like an obstacle course. When you’re coding yourself you’re going to bang into more gotchas, and more importantly when you’re stuck on that random inexplicable problem that doesn’t make sense, with two sets of eyes and brains on the problem you’re likely to find the solution (or find a completely different way to sidestep the problem) much sooner than individually. I’d argue it’s this un-blocking ability that pair programmers have that makes them more productive than two (siloed) individual coders.
80:20
Pair programming doesn’t mean you both have to go to the loo together, - I’m also not convinced there’s a case for pair email reading. There’s also bits that are clear and you’re both in agreement with - you can divide and conquer those bits. But the meat, the important bits, the urgent production problems - these are crucial to be pair programmed.
You get higher quality and counter-intuitively it’s cheaper.
| If the boss asks, just say you’re doing a code review… |