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

RE: [agile-usability] Real data

Expand Messages
  • Glen B. Alleman
    If I turn the Safety and Mission Assurance team sitting down the hall, they ll say yes things do fail, how can we prevent that through proactive
    Message 1 of 218 , Feb 1, 2010
    • 0 Attachment
      If I turn the Safety and Mission Assurance team sitting down the hall,
      they'll say "yes things do fail," "how can we prevent that through proactive
      intervention, design, testing, and Mission Assurance process."

      "Letting failure emerge is not an option," might be the summary.

      > -----Original Message-----
      > From: agile-usability@yahoogroups.com [mailto:agile-
      > usability@yahoogroups.com] On Behalf Of Ron Jeffries
      > Sent: Monday, February 01, 2010 3:52 AM
      > To: agile-usability@yahoogroups.com
      > Subject: Re: [agile-usability] Real data
      > Hello, William. On Monday, February 1, 2010, at 1:35:06 AM, you
      > wrote:
      > >> Yes. But how many shuttles have to explode in flight before "Failure
      > >> is not an option" is see for the BS it is?
      > > That's interesting. Are you suggesting the mental progression is
      > > something like
      > > 1. "Failure is not an option!"
      > > 2. "Failure is unthinkable."
      > > 3. "I won't think about failure."
      > > 4. "That thing that might indicate failure? I'll ignore it."
      > > 5. "All signs points to success."
      > > 6. "That failure that just happened? Nobody could have predicted
      > it."
      > Perhaps. My point is simpler: Things do fail.
      > Ron Jeffries
      > www.XProgramming.com
      > www.xprogramming.com/blog
      > For me, XP ain't out there, it's in here. -- Bill Caputo
      > ------------------------------------
      > Yahoo! Groups Links
    • 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
      • 0 Attachment
        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.