Comparison of Change Management Systems

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! 3
Peer code review has the potential
to take too much time to be worth the
gain in bug-fixing, code maintainability,
or in mentoring new developers. The
techniques that provide the benefits of
peer code review while mitigating the
pitfalls and managing developers’ time
are competitive advantages that no one
wants to reveal.
Unfortunately for these successful
software development organizations,
we make a living making code review
accessible and efficient for everyone.
And that’s what this book is about.
I’m interested. What next?
So code review works, but what if
developers waste too much time doing
it? What if the social ramifications
of personal critiquing ruin morale?
How can review be implemented in a
measurable way so you can identify
process problems?
We cover case studies of review in the
real world and show which conclusions
you can draw from them (and which you
can’t). We give our own case study of
Software Testing
2500 reviews. We give pros and cons for
the five most common types of review.
We explain how to take advantage of the
positive social and personal aspects of
review as well as ways managers can
mitigate negative emotions that can
arise. We explain how to implement
a review within a CMMI/PSP/TSP
context. We give specific advice on
how to construct a peer review process
that meets specific goals. Finally, we
describe a tool that our customers have
used to make certain kinds of reviews as
painless and efficient as possible.
Code review can be practical, efficient,
and even fun.
1 Income primarily from the “Adobe Intelligent
Documents” division, defined with financial
figures in Adobe Systems Incorporated Letter to
Stockholders FY 2005.
2 “At the heart of our enterprise strategy are
the free and ubiquitous Adobe Reader software
and Adobe Portable Document Format (PDF).
Adobe Reader enables users to view, print, and
interact with documents across a wide variety of
platforms.” Ibid, page 6.
3 Some companies have published case
studies on effectiveness of heavyweight
inspection processes. In our experience, the
overwhelming majority of code review processes
are not heavyweight, and those studies are often
statistically-insignificant. Details on this and our
own case study are given in the essays, “Brand
New Information” and “Code Review at Cisco
Systems.”
65