software design it can also work when writing code. Peer code review adds a much-needed collaborative element to the development phase of the software development process.
The $1 billion bug
In 2005, Adobe attributed $1 billion in revenue to their stronghold on the PDF format (see Adobe Systems Incorporated Letter to Stockholders FY 2005 ).
Why is PDF worth $1 billion? Because it's the one format that everyone can view and print (see same document). It just works. If it loses that status, Adobe loses the edifice built on that format, to which the fiscal year 2005 income statement attributes $1 billion.
Now imagine you are a development manager for Acrobat Reader, Windows Edition. The next major release is due in 9 months and you are responsible for adding five new features. You know how much is riding on Reader and how much revenue - and jobs - depends on its continued success.
So now the question: Which of those five features is so compelling, it would be worth introducing a crash-bug in Reader just to have that feature?
Nothing is worth losing your position in the industry. But you still must implement new features to keep the technology fresh and competition at bay. You must employ every possible technique in your development process to ensure that no bugs get introduced.
Only code review will ensure that this code base - already over ten years old - remains maintainable for the next ten. Only code review will ensure that new hires don't make mistakes that veterans would avoid. Static code analysis and black-box QA will not do this for you. And every defect found in code review is another bug that might have gotten through QA and into the hands of a customer.
This doesn't mean they implement code review no matter what the costs; developer time is still an expensive commodity. It does mean that they're taking the time to understand this process which, if implemented properly, is a proven method for significantly reducing the number of delivered bugs, keeping code maintainable, and getting new hires productive quickly and safely.
But you don't need to have $1 billion at stake to be interested in code quality and maintainability. Delivering bugs to QA costs money; delivering bugs to customers costs a lot of money and loss of goodwill.
But if code review works this well, why don't more people talk about it? Is anyone really doing it?
Why code review is a secret
In 1991, OOP was the Next Big Thing. But strangely, at OOPSLA there were precious few papers, light on content, and yet the attendees admitted to each other in hallway talk that their companies were fervently using the new techniques and gaining significant improvements in code reusability and in breaking down complex systems.
So why weren't they talking publicly? Because the development groups that truly understood the techniques of OOP had a competitive advantage. OOP was new and everyone was learning empirically what worked and what didn't; why give up that hard-earned knowledge to your competitors?
A successfully-implemented code review process is a competitive advantage. No one wants to give away the secret of how to release fewer defects efficiently.
When we got started no one was talking about code review in the press, so we didn't think many people were doing it. But our experience has made it clear that peer code review is widespread at companies who are serious about code quality.
But the techniques are still a secret! Peer code review has the potential to take too much time to be