Loading ...
Sorry, an error occurred while loading the content.

Re: [scrumdevelopment] the non agile way

Expand Messages
  • Phlip
    ... I didn t get that. What I got was they do XP in incredibly slow motion (with an incredibly high staff count). Where we refactor mercilessly and integrate
    Message 1 of 34 , Apr 27, 2005
    • 0 Attachment
      hal arnold wrote:

      > Having spent my early career in the arms of the
      > 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...

      I didn't get that.

      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.

      --
      Phlip
    • Michael James
      ... I worked on several such systems (in Ada, of course), and often saw thoroughly polished, clearly written, well designed (and over-documented) code. On my
      Message 34 of 34 , Apr 28, 2005
      • 0 Attachment
        --- In scrumdevelopment@yahoogroups.com, Phlip <phlip2005@g...> wrote:
        > 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.

        I worked on several such systems (in Ada, of course), and often saw
        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
        changes though.
      Your message has been successfully submitted and would be delivered to recipients shortly.