Re: [scrumdevelopment] the non agile way
- hal arnold wrote:
> Having spent my early career in the arms of theI didn't get that.
> defense industry, I'd sure like to see that code. If
> it's anything like I suspect, it may be 'correct' but
> not very pretty, which points out other differences
> between non and agile processes...
What I got was they do XP in incredibly slow motion (with an
incredibly high staff count).
Where we refactor mercilessly and integrate continuously, they slowly
and ponderously refactor, one line at a time, from the requirements to
the code to the tests. Then they integrate step-wise, by pushing the
change onto a conveyor belt for review by other humans, testers, the
opposing team, etc.
With dozens of years and hundreds of coders, their code is probably
very clean and readable. You couldn't stomp in a change for tomorrow's
launch, but they all know that code clarity affects the bug rate, and
they know to clean it up.
- --- In email@example.com, Phlip <phlip2005@g...> wrote:
> With dozens of years and hundreds of coders, their code is probablyI worked on several such systems (in Ada, of course), and often saw
> very clean and readable. You couldn't stomp in a change for tomorrow's
> launch, but they all know that code clarity affects the bug rate, and
> they know to clean it up.
thoroughly polished, clearly written, well designed (and over-documented) code.
On my favorite process-heavy project we had a 3 to 1 ratio of verification engineers
to design engineers, and the review process was almost as good as pair
programming. A lot of informal pairing sprung up anyway, since everyone
was so afraid of submitting mistakes.
At one point we were organized into groups of about six, with a verification
engineer in charge of each group. That worked pretty well, but was dismantled
for stupid political reasons.
Even changes to the automated tests (which had damn near 100% code
coverage) had to be thoroughly reviewed and approved by a change-control
board like everything else. In this case we survived because the requirements
were relatively stable. It wasn't as good as Agile, but it was a better way to
build airplanes than Chaos.
I'm guessing cost per line of code was 20 times higher than the Java stuff
I'm doing now. I'd hate to imagine the cost (or even the feasibility) of