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

Re: the non agile way

Expand Messages
  • 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 1 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.
    • 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.