Code Reviews vs. Pair Programming?
In my previous post I questioned the popularity of peer reviews in the real-world. I claimed that there might be a good reason that most organizations are not practicing systematic peer reviews: the nature of peer reviews causes too much overhead and context switching, which makes them ineffective for the long run.
But what about Pair Programming? Pair programming is often described as “continuous code review”. After all, two pairs of eyes are always watching the code. Isn’t that what code review is all about?
Dave Nicolette’s latest article mentions “after the fact” code reviews as a symptom for suboptimal development:
“Code reviews are a second-best alternative that must be used when the team cannot or will not use TDD, pair programming, or other proactive means of ensuring clean code. Excessive emphasis on code reviews is a symptom that development methods may be suboptimal.”
I beg to differ.
Let me start with the bottom line: I don’t have anything against pair programming. On the contrary. For some people and in some projects pair programming can be a great development method. However, whether you code alone or in pairs (or in groups of four for that matter) is completely orthogonal to the issue of having code reviews.
Pair programming don’t replace code reviews, just as code review don’t replace pair programming. Despite of how pair programming is referred to, the two techniques have little to do with each other.
If you’ve ever attended a good, thought-provoking code review in which the code and the design were thoroughly analyzed by someone who wasn’t part of the actual implementation activity, you will probably find it hard to say that pair programming can replace it.
When you work in a pair, it is quite easy to find local defects, identify inconsistencies with standards, and discuss some design decisions as you go. But most of the time, the pair works as one. From a certain point, the pair thinks as one. When you are in the eye of the storm it is much harder to spot more profound problems.
Nothing can replace an “objective” pair of eyes. Someone who was not part of the actual implementation activity. Someone who isn’t emotionally attached to the code. A professional reviewer often raises issues that are in the blind spot of the developers writing the code – whether they worked as a pair or not.
Even when we consider the physical aspects of pair programming it is apparent that its benefit as a reviewing method is limited. The developer who is currently not coding does not control what is seen on the screen. He cannot navigate within code freely. This lack of physical control over the code limits the developer’s ability to analyze the code thoroughly. Just like reading the code from paper.
Code reviews are a good thing! When done properly they greatly increase the quality of the design and of the code. Pair programming might reduce the number of relatively local problems in the code, but this does not mean a thorough review won’t significantly improve it even further. Chances are that it will.
As life often teaches us, not everything is more effective when pushed to the extreme. Reviewing the code literally 100% of the time using pair programming as a platform makes the review less effective. Pair programming has a lot of benefits, but it cannot replace professional reviews. Weekly professional reviews done by a professional mentor are much more effective in improving code quality and enriching the experience of developers.
The good news is you don’t need to choose between code reviews and pair programming. Just do both!
July 12th, 2006 at 7:35 am
I’d agree with your analysis of the situation - but what is a team (or individual, for that matter) to do when the realities of life preclude either pair programming *or* code reviews? Sometimes the political climate doesn’t allow for such “radical” deviance from established process - or maybe there is a genuine lack of available manpower to do such reviews/pair programming, and no funding to hire additional staff.
Obviously one could argue that time invested in good reviews or pair programming would yield a high enough ROI that net productivity does not suffer (and should in fact improve), but what if it’s not an option to try it?
Is there hope in such cases? What can be done to mitigate the tendency for people to go off and create foul code in isolation, under such constraints?
July 12th, 2006 at 8:57 am
Hi Apoch,
The question you raise is THE MOST important question in the context of optimizing software development.
In my previous post about code reviews in the real world I brought code reviews as an example of a good practice everyone knows and talks about yet only few organizations actually practice.
For some strange reason many organizations are blind to the simple economic calculation. In that sense, these organizations operate against their best interest. Now the question is what can you do about it.
As you might guess, I don’t have a generic answer. I think no one has. The answer depends on your organizational culture, on the people you work with, and on the people you work for.
The only general advice I can give you is to keep trying to push these good practices forward in your organization. You have to nag, but you have to do it gently (at least most of the time). Backup your agenda with real-world data. Gather some data from your own workplace as well. Hopefully, when management sees real numbers, it won’t be able to ignore them. Hopefully.
In any case, you will have to use a lot of common sense and hope your management will too.
Good luck,
Lidor
PS. You can always invite an external consultant (such as myself) to back you up as well ;)
July 12th, 2006 at 10:55 am
Apoch,
It sounds like you work in a very traditional organization. While you might not be able to get direct management approval or support for practices like pair programming, test-driven development, or code reviews, you and your colleagues can use those practices on your own initiative.
Controlled studies have shown that a pair takes about 15% more time to develop a given amount of code than two people working separately, so the impact on your project schedule will be minimal. At the same time, the studies show pair programming results in fewer defects in the code, so you can offset the additional coding time with less debugging time.
Other studies have shown that TDD reduces defects while adding nearly nothing to development time. TDD is a practice you can do alone or in a pair. Since you will undoubtedly write unit and integration tests anyway, your traditionally-minded manager will not know whether you wrote the tests before you wrote the code.
I’m not entirely sure I understand how you can have too few resources to do code reviews or pair programming. You only need, at a minimum, two people to do either.
If your working environment is as “traditional” as it sounds, then probably your manager does not stand around and watch you work, and he/she probably would not be able to tell the difference between unit test cases and application code even if he/she saw what you were typing. In that admittedly twisted way, a traditional environment actually offers a certain amount of scope for innovation at the grassroots level.
Some time ago I blogged about how we got an agile practice started internally at my present employer three years ago. The low level IT management layer is definitely the most resistant to change. We went around that layer altogether and made a “deal” directly with the manager of a business unit to do an agile project “on the side”. Once the customer saw the results of that project, she talked it up with her peers and before long customers were explicitly requesting their projects be done with agile methods. That way, we avoided direct confrontation with IT management. You might try something along the same lines. The worst thing that could happen is that you might lose a job you don’t like.
July 12th, 2006 at 5:02 pm
I just wanted to share the process we use at work. We’re a web/media company so we’re alway working on essentially the same “application” all the time so this might not be optimal for everyone.
Basically EVERY line of code gets reviewed at checkin. We code on our own, but as soon as anything goes into the source respository we have to call another developer over to give the ok. Every checkin stores who checked it in and who reviewed it and responsibility over defect is shared fairly evenly over who wrote it and who approved it, giving us the incentive to actually look hard at code.
It works very well for us. You get a feel for looking at small changes and glancing over those pretty quickly and you’ve got the developer right there to explain any architectural assumptions or whatever. For new pages we review in the IDE, any revisions to existing code are reviewed using windiff so any changes are highlighted.
The other good thing about the reviews for us is that we have a few different backend systems (mostly from integrating with legacy systems) and the reviews give us all the chance to have a fair understanding of systems we’re not currently working on.
July 13th, 2006 at 3:48 am
I should probably clarify my situation - the problems are not organizational, they’re practical. To put it quite simply, I’m not on the same continent as the rest of my team - and a couple other members are in a similar situation :-)
The other clincher is that there is a lot more work to be done than people to get it done, and the financial reality is that nobody new will be added any time soon. That’s the lack-of-resources problem; even a 15% increase in development time means a schedule slippage somewhere in the pipeline, and that means bad news. Personally I’m fully convinced that we could be saving time in the long run by fixing our process; the challenge isn’t convincing anyone else (management is remarkably receptive to the idea in principle). The challenge is making the change without disrupting the precarious stability of the business.
July 14th, 2006 at 12:32 am
Hi Apoch,
The reality you are describing is indeed challenging. The main challenge is stepping out of the loop and actually improving the way you work. Of course this should be done with minimal impact on your business.
I invite you to contact me if you would like to discuss the concrete challenge you are facing personally:
http://www.qualityaspect.com/Contact/
Lidor
July 15th, 2006 at 11:30 am
I like to apply different approaches to different projects. Being able to improvise in such ways because of a fairly versitile corporate environment is very helpful to the bottom line. We’re able to pair up if we feel it makes sense. Also, if we think we’ve gone just a little too far on a project without sitting back and reviewing how we’ve approached many of the implementations, we can take a little time to review our approaches and look at some of the best practices we applied.
Being versitile in each project can be helpful in the cases where some projects may not merrit a full-fledged code review, or the concentration of two people to develop it. However I think the benefits of both are definitely evident depending on the project.
April 25th, 2007 at 5:05 pm
Welcome to our website for you World of Warcraft Gold,Wow Gold,Cheap World of Warcraft Gold,wow gold,buy cheap wow gold,real wow gold,sell wow gold, …
Here wow gold of 1000 power leveling wow gold at $68.99-$80.99,World Of Warcraft Gold,buy wow gold,sell world of warcraft gold(wow gold),buy gold wow lightninghoof instock Cheap wow gold,cheapest wow gold store …
May 21st, 2007 at 10:27 pm
welcome to www.wow-of.com. the cheapest price,the fastest delievery.We strives to offer the fastest and most reliable service on the web for all your gaming needs. Feel free to contact us 24 hours a day, 7 days a week by phone, live chat and email.
Welcome to our website for you World of Warcraft Gold,Wow Gold,Cheap World of Warcraft Gold,cheap wow gold,buy cheap wow gold,real wow gold,sell wow gold, … Here wow gold of 1000 gold at $39.99-$49.9,World Of Warcraft Gold,buy wow gold,sell world of warcraft gold(wow gold),Cheap wow gold,cheapest wow gold store … wow gold–buy cheap wow gold,sell wow gold.welcome to buy cheap wow gold–cheap, easy, wow gold purchasing.World of Warcraft,wow gold Super … We can have your wow gold,buy wow gold,wow gold game,world of warcraft gold,wow Gold Cheap wow, Cheap wow gold,world of warcraft gold deal,Cheap WOW Gold … Welcome to our website for you World of Warcraft Gold,Wow Gold,Cheap World of Warcraft Gold,wow gold,buy cheap wow gold,real wow gold,sell wow gold, … Here wow gold of 1000 gold at $39.99-$49.9,World Of Warcraft Gold,buy wow gold,sell world of warcraft gold(wow gold),Cheap wow gold,cheapest wow gold store … wow gold–buy cheap wow gold,sell wow gold.welcome to buy cheap wow gold–cheap, easy, wow gold purchasing.World of Warcraft,wow gold Super …
June 18th, 2007 at 12:44 am
wow gold is the most valuable form of currency in buy wow gold site offers free World of Warcraft Gold Guides, Farming Strategies, Tips, Hints, & Cheats that will help you make over 1000 WoW Gold Fast and Easy. World of Warcraft is a best-selling Massively Multiplayer Online Game (MMOG) set in Blizzard’s Warcraft universe. Players assume the roles of heroes as they adventure, explore, and quest together across a vast world. World of Warcraft cheap wow gold ships simultaneously for Mac and Wind.
September 21st, 2007 at 3:32 am
290154687607
the page linked to the
January 20th, 2008 at 12:50 pm
Thanks for the nice read
March 16th, 2008 at 5:03 am
Successful website
March 30th, 2008 at 6:29 pm
宿州之窗
[url=http://www.sz-window.com]宿州之窗[/url]