Jerry said:
Pair programming (at least from what I've seen) normally implies one
person sitting at the keyboard, and another looking over their shoulder.
Pair programming involves two programmers with dual keyboards & mice. They take
turns typing, and they both know the plan in their heads. Either could take over
typing for the other at any time. If one thinks of a better plan, they type and
describe it, out loud, until the other could take over.
I think there's a much more damaging aspect than that. People use it as
a straw man when presenting their new and improved methodology.
Waterfall most certainly is not a strawman.
For a small project - such as one feature within an otherwise iterative cycle -
"Waterfall" casually refers to exactly what James Kanze advocates - sketching a
complete design before committing it to code. That is "Big Design Up Front", and
it's not really the worst possible system. It's better than Code-n-Fix. Those
who practice TDD have learned to do without it and produce competitive designs.
For a large project, the worst part of Waterfall is the understandable urge to
collect all possible requirements before beginning the project. That is the
worst system possible. For example, I once temped at a company that had
established a successful biz-to-biz website, at the expense of very crufty code.
They had diligently followed Waterfall, collected requirements, designed them,
and then coded them. No tests.
The problem with calling Waterfall a "strawman" is these senior software
engineers and managers actually thought the software engineering literature TOLD
THEM to follow this incorrect process.
Then the inevitable happened. Real world requirements appeared and conflicted
with the planned requirements. At this point, the design quality went over a
cliff. To rapidly add new features to a deployed application, the programmers
had to start adding hacks and patches. Did I mention the code had no tests?
Even
thogh all they talk about is its problems, the message that's often
received is that it's the best available alternative to the methodology
being preached at the moment.
Exactly. And I was there when the managers had a little dinner together to
celebrate a successful quarter, and to plan a rewrite. Of course it was going to
be in Java, and coded by an outside team. And I actually got to hear with my own
ears the second-in-command manager saying, "This time, we will spend lots more
time planning the requirements, and getting them all right before we start".
Waterfall most certainly is not a strawman, despite its use as a simple contrast
to Agile in the literature. Waterfall reappears whenever managers see new
requirements afflict old code, and they think this means they must collect
_more_ up front requirements.
Whenever you hear in the news of a billion dollars sunken in some huge abandoned
software project, you can bet money that its managers started with a big
requirements gathering session. The more requirements gathered, the more likely
the failure, simply because each requirement represented a decision made with
the least hard data possible.
In hardware, compare the processes of GM to those of Toyota. 'nuff said!
The people attempting to "kill" the waterfall methodology are the ones
who are almost entirely responsible for it being put to use at all.
Without it's being taught as the prevailing and accepted method, nobody
would accept the utterly insane idea that each step must be completed to
perfection before the next step is started, nor that each step must be
treated as sacrosanct once completed, no matter how serious of flaws are
found later in the process.
To do Waterfall right, each time you find a mistake, you must go back to the
phase that created mistake and start from there again.
Given arbitrary time and arbitrary programmers, that works great!
