|
Wednesday, 27 September 2006 |
Aren't code reviews a waste of developer time? That's what QA is for!
Forget ROI and cost ratio charts for a second. What's the common-sense argument for peer code review?
Here's a common-sense argument:
While writing my book I asked several professional editors about what it's like reviewing prose. The general consensus was that every page of prose contains about 10 errors. This is true even with professional writers (which I am not).
None of us can write a page of prose without commiting various errors of style, clearness, and grammar. Not even professionals. Writers are too close to the content to step back and see problems. And writers just need another set of eyeballs pointing out the "obvious" flaws.
It's not the end of the world. It's just how humans work.
Now consider your software developers. They write reams of code. Often many pages of code per day. Oh, and prose too (or do your developers not write comments?).
Do you expect them to write perfect, glistening code without any editorial work? No little mistakes? No subtle algorithm problems? No need to consult with the group's expert on certain matters?
Human editors work for prose; it's sensible that it might work for code.
But you don't want to waste precious developer time. Is the time taken during review worth the defects you remove? Now you're talking about data... but before we get there, consider this:
With requirements and design work we always have peer review. We often
collect data in private but always synthesis in meetings and agree in
groups. We argue pro's and con's of various choices. When we're done
we're confident that we've beat the horse to death and did our best to
turn over good ideas to the development team.
So why don't we do this during development? OK, we can't afford to have a full-fledged meeting for every little code change, but isn't it sensible that some review would be useful with some of the code? Maybe when we make changes in the "stable" code branch? Or when we change a core module? Or just when working on a complex problem?
Now that you have the common-sense argument, you might want to read some stories and get some data. For that, check out Part 1 of my 8-part article series on Lightweight Peer Code Reviewer here on CM Crossroads.
Trackback(0)
 |
|
Last Updated ( Wednesday, 27 September 2006 )
|
TrackBack URI for this entry
Subscribe to this comment's feed
