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

Re: [agile-usability] Real data

Expand Messages
  • Michael James
    ... This discussion reminds me of a particular incident building one of the thousand subsystems on an airliner in the early 90s. One of the good things about
    Message 1 of 218 , Feb 1, 2010
      On Jan 31, 2010, at 11:44 PM, William Pietri wrote:

      However, although I've 
      seen or heard about a number of messy failures, I've never seen the 
      punishment compensate for the failure.

      This discussion reminds me of a particular incident building one of the thousand subsystems on an airliner in the early 90s.  

      One of the good things about the processes we used then was much more design/code review than occurs on typical commercial software.  In this case I was in the role of "verification engineer" reviewing someone's code that was supposed to persist data to NVM.  The NVM was only rated for 100,000 write cycles, and our box was required to handle write failures gracefully.  I noticed his code had conditions it wouldn't detect an NVM failure, so I logged defects against it.  The change control board would not allow him to change the code without me doing this.  Also we were in completely different reporting structures, per our Independent Verification & Validation requirements.  

      When my change request was approved, he responded by making code changes that fixed the specific instances I found, but introduced new cases an NVM failure could cause undesired system behavior.  So eventually that came back to me for review, and I reported new defects.  At this point we were both probably working 70 hour weeks because the design/code phases had been declared "done" months ago.  This cycle continued so many times that an auditor (either from the FAA or the customer -- can't remember) showed up to interview us about the defects and I vaguely recall a big management meeting about it.  

      THE SOFTWARE PROBLEM WAS NEVER SOLVED THOUGH.  Probably some risk assessment accepted it as a known limitation, mitigated by all the other redundancies in the larger system.  Maybe they found more durable NVM, or made a point of replacing it before it got to 100,000 write cycles.  I still feel safe on that airplane.

      Despite what any academic study purports to show, I know we could have achieved a greater amount of quality in less time with a tighter feedback loop between the verification/validation process and the design/code/build process, as advocated by the Agile movement.  

      --mj (who finds this discussion interesting, but wonders why it's happening on the "agile-usability" list!)

    • George Dinwiddie
      Hi, Jon, ... I ve never found creating software to be a one and only time no matter how small the program. There s a lot of similarity between writing one
      Message 218 of 218 , Feb 12, 2010
        Hi, Jon,

        Jon Kern wrote:
        > ok, maybe it is silly to debate the term...
        > George it's a free country, use method anytime you please :-)
        > I personally will only use "method" when I want to describe some way
        > that I achieve something over and over. Often in an abstract sense,
        > often in a step-wise way. Often because the "something" is a desirous
        > end goal, and one that I (or someone else) wants more than one time.
        > I would not describe the /ad hoc/ "how" of the one and only time I will
        > ever do something as a "method" if it is not.

        I've never found creating software to be a "one and only time" no matter
        how small the program. There's a lot of similarity between writing one
        line of code and writing the next.

        And I've observed, that people generally continue to do something
        somewhat in the fashion they've done it before. Thoughtful people will
        consider the result their achieving, and modify their actions to try to
        improve some aspect.

        I've never seen anyone continue to approach the work as if they'd never
        done anything like it before, choosing some completely different way of
        working. And I've never seen anyone carefully follow the recipe in a
        process manual. At best, a process manual gives the worker some ideas.

        It's the process people actually /do/ that has an effect. If you and
        Scott and Glen want to reserve the word "method" for officially blessed
        procedures, go right ahead. It won't change a thing.

        - George

        * George Dinwiddie * http://blog.gdinwiddie.com
        Software Development http://www.idiacomputing.com
        Consultant and Coach http://www.agilemaryland.org
      Your message has been successfully submitted and would be delivered to recipients shortly.