Seven Sins of SW Reviews
1. Participants Don't
Understand
the Review Process
my opinion: I agree that
participant might often
not have a clear idea as
to what they are asked
to do. But, as the article
suggests, a training will
solve this problem. Yet,
I consider that more
than 8 hours are needed
to delve in the subject.
2. Reviewers Critique
the Producer,
Not the Product
my opinion: I could not
agree more with this
particular issue. Indeed,
people often get personal
and aggressive when
dealing with collective
problems. I would offer
my own solution: hire a
conflict manager or an
internal mediator.
3. Reviews Are
Not Planned
my opinion: This issue
seemed to me a little bit
common sense. Indeed, a
review should be a planned
activity. But then, shouldn't
it be thought of such
in the first place, like any
other activity performed
in a SW design
process?
4. Review Meetings
Drift Into
Problem-Solving
my opinion: Well, only
focusing on the problem
and not the solution is
definitely easier said, than
done. People will every
so often try to jump in "for
help". I love the author's
solution: if problem solving
takes less than 1 minute, go
for it. But then: who will keep
track of this 1 min time?
5. Reviewers Are
Not Planned
my opinion: Here, what the
author points out seems to
me an essential problem:
lack of preparation will drag
the whole meeting down. I
too think supplying the re-
viewers with enough time
and documentation is the
key to success.
6. The Wrong
People Participate
my opinion: The rule of
thumb suggested by the
author is having 3-7 people
participate in the review
process, mostly those implied
in the code production or
affected by its result. I would
probably add a highly skilled
senior SW developer to help
with this.
7. Reviewers Focus
on Style, Not
Substance
my opinion: Indeed, many
people focus on style, rather
that code essentials, just like
a good majority of us finds it
hard to perceive a message,
when the grammar is faulty.
Probably, having "slyle team"
and "defects team" would help
on this matter.