I used Jerry's (a), and (b) as notes in my comments:
> a) find & fix problems early (even before the customer...)
> b) reduce time to market (less debugging, more reuse)
I just read an article about how a successful software company is "like a
hive of bees." The management can't talk to them--all they can do is take
the honey. But soner or later, it gets taken over by someone who thinks
"C++ is a decent grade, almost a B-." "They actually expect programmers to
PLAN their work." So the product "loses market share" with "code bloat"
and lots of bugs.
This writer thinks the "normal" way to avoid "code bloat and lots of bugs"
is to stay in your cave hacking until the code is "tight, fast, and cool"
and emerge a "hundred pounds heavier" when "judging by the pizza boxes, it
must be spring." (b)
Ironic that in this one-page article, during casual reading, I counted at
least five spelling errors and at least two grammar errors.* I should
trust him to talk to a computer in C++ when not even his editor/publisher
can make his native language correct? (a) (The author probably thinks a
"code review" is that column in "PC Week" with all the pleasant adjectives.)
* No offense to Teamers whose native language is not English. I expect
harmless errors from them (especially since I have made not so harmless
errors trying to speak French). Our friends in France, Belgium, and
Holland handle English as good as or better than that writer.