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

Re: Comments on Silver Bullets

Expand Messages
  • Brad Grant
    I echo Monique s comments. Moreover, IT mgmt that realize a successful agile project and wonder why we can t always function like this. Or even
    Message 1 of 14 , Jan 16, 2004
      I echo Monique's comments.

      Moreover, IT mgmt that realize a successful agile project and wonder
      why we can't always function like this.
      Or even development-staff tailcoaters who fail to understand the
      discipline and dedication undertaken to achieve a quality iteration.

      Brad

      --- In scrumdevelopment@yahoogroups.com, "Monique L. Attinger"
      <monique@a...> wrote:
      > Ken -- I think this article is a timely 'reality check'. While I'm
      not sure
      > where you are looking to 'publish' this, I suspect that there are
      multiple
      > audiences who could benefit: 1) non-IT management who think that
      we can do
      > more and more with less and less until we are making everything
      out of
      > nothing, and 2) IT professionals who have bought into the myth
      that there is
      > some kind of way to build software which takes away the difficulty
      of
      > working with other people and who think everything would be fine
      if only
      > they didn't have to deal with 'end losers'.
      >
      > Monique Attinger
      > -----Original Message-----
      > From: Ken Schwaber [mailto:ken.schwaber@v...]
      > Sent: January 16, 2004 10:57 AM
      > To: scrumdevelopment@yahoogroups.com
      > Subject: [scrumdevelopment] Comments on Silver Bullets
      >
      >
      > I'm looking for comments on the following "article."
      > Ken
      >
      > Silver Bullets
      >
      > I don't know if other industries fall prey to the silver bullet
      myth as
      > hard
      > as systems development. The belief that there will be some
      magical
      > incantation, tool, or facility that will kill the difficulty of
      software
      > development has haunted our industry as long as I've been
      developing
      > software, and I remember the 60's. In some ways the belief in
      the silver
      > bullet was good; it fueled the growth of whole tool industries -
      remember
      > Computer Aided Software Engineering tools from Index Technology,
      > Knowledgeware, and a host of other companies? Remember models
      that were
      > supposed to generate code that could be maintained from the
      model?
      > Remember
      > heavyweight methodologies?
      >
      > A test for the presence of a silver bullet is, "does using this
      somehow
      > make
      > the practice of building software for me and those who work with
      me
      > substantially easier in a way that I don't fully understand?" If
      the
      > answer
      > to this is "yes" and this thing costs money and is being sold by
      a
      > company,
      > inspect it thoroughly before buying and implementing it.
      >
      > I'm not against magic or simplification. Our jobs of building
      quality
      > software are hard enough that I believe that we can be forgiven
      for
      > looking
      > for ways to simplify them. We can even be forgiven for spending
      lots of
      > time
      > and money acquiring and trying to use silver bullets. In the
      process, we
      > usually learn something useful, like how to graphically
      represent our
      > ideas
      > methodically and rigorously. What we won't be forgiven for are
      both the
      > degree to which these silver bullets have reduced our ability to
      produce
      > quality software on time and with required capabilities, and the
      degree to
      > which they've made it so that we speak separate languages from
      our
      > customers. I once even taught a course in data modeling to a
      group of
      > actuaries at an insurance company so that they could understand
      their
      > systems.
      >
      > Agile processes are sometimes though of as silver bullets. "All
      I have to
      > do
      > is implement Scrum throughout my organization and things will be
      better"
      > is
      > becoming a mantra, following closely on the heels of "all I have
      to do is
      > implement XP and things will be better." This statement is
      usually made by
      > senior IT or software engineering management after one or
      several projects
      > is miraculously turned around and becomes vividly successful
      after XP
      > and/or
      > Scrum is applied. The problem is that the success of the few is
      difficult
      > to
      > replicate in the many. The reason is the shortage of people who
      know what
      > they are doing.
      >
      > The idea behind most silver bullets is that almost anyone can
      successfully
      > build systems, as needed, using the silver bullet. Agile
      processes come in
      > with a different tenet: software development is difficult work
      and here is
      > a
      > framework and set of practices within which to engage and manage
      teams in
      > this difficult work. No attempt is made to say that the work is
      easy or
      > can
      > be done by junior, indifferent, or incompetent employees.
      Instead, agile
      > processes simply make the impact of unskilled professionals very
      apparent
      > very quickly. Skilled professionals generate quality systems
      using agile
      > processes. Unskilled professionals produce terrible systems
      using agile
      > processes. What agile processes bring to this game is that the
      bad work of
      > the unskilled professionals becomes quickly apparent and must be
      dealt
      > with;
      > it won't go away and won't become invisible. Many methodologies
      keep
      > unskilled work hidden until the end of the project, and some
      even keep the
      > results hidden until someone attempts to sustain, maintain, or
      enhance it.
      > Agile processes show the bad quality every day and at the end of
      every
      > iteration.
      >
      > Agile processes are hard work. If everything that isn't going
      well is put
      > in
      > management's face every day and at the end of every iteration,
      life isn't
      > very pleasant. It isn't that all of these problems weren't
      always present;
      > it's just that now they are out in plain sight and pointed out
      to everyone
      > very frequently. Part of my work helping people implement agile
      processes
      > is
      > getting them through the despair they initially feel when they
      see all the
      > problems. I call these problems the good news and the bad news:
      the good
      > news is that you can now begin methodically fixing these
      problems; the bad
      > news is that you know that they need to be fixed (and so does
      everyone
      > else).
      >
      > Agile processes keep the bad news visible until it is fixed. If
      developers
      > aren't testing their code, this is evident at least every
      iteration, and
      > often every day. If developers aren't checking in and building
      their code
      > frequently, this becomes visible every day. These problems stay
      visible
      > until engineering practices are implemented to fix them.
      Management is on
      > the hook to get them fixed as well as to devise strategies to
      remedy the
      > problems until they are fixed.
      >
      > Agile processes ruin perfectly good management jobs, where
      managers sit in
      > corner offices reading reports and presuming good progress until
      the
      > project
      > fails. Agile processes stick the bad news in the face of
      managers daily;
      > the
      > "plausible deniability" offered by most silver bullets is
      totally removed.
      > The good news is that you can build great software predictably
      with agile
      > processes. The bad news is that it is really hard.
      >
      >
      >
      > To Post a message, send it to: scrumdevelopment@e...
      > To Unsubscribe, send a blank message to:
      > scrumdevelopment-unsubscribe@e...
      >
      >
      >
      > -------------------------------------------------------------------
      ---------
      > --
      > Yahoo! Groups Links
      >
      > a.. To visit your group on the web, go to:
      > http://groups.yahoo.com/group/scrumdevelopment/
      >
      > b.. To unsubscribe from this group, send an email to:
      > scrumdevelopment-unsubscribe@yahoogroups.com
      >
      > c.. Your use of Yahoo! Groups is subject to the Yahoo! Terms
      of Service.
    • Nancy Van Schooenderwoert
      ... About the 2nd paragraph - At the end of it, I was hoping for an example. It got me thinking that source code control tools make life substantially easier,
      Message 2 of 14 , Jan 18, 2004
        On Fri, 2004-01-16 at 10:57, Ken Schwaber wrote:
        > I'm looking for comments on the following "article."
        > Ken

        About the 2nd paragraph - At the end of it, I was hoping for an
        example. It got me thinking that source code control tools make life
        substantially easier, and I DO completely understand what they do - so
        that's not a silver bullet. I'll say that tools purporting to generate &
        maintain code directly from UML diagrams are a silver bullet because I
        don't fully understand how they can do it, and I haven't seen one fully
        prove itself.

        The fourth paragraph points out the shortage of people who know what
        they are doing. Reading this as a manager I'd want to know more about
        how I can tell who does know what they're doing. I suppose that's a
        different article. Just the same, it's a great spot to have a pointer to
        info on that topic.

        Fifth paragraph - You may wish to tie this insight ( agile processes
        simply make the impact of unskilled professionals very apparent very
        quickly ) to the "don't shoot the messenger" classic advice. The old
        fashioned thing was to yell at the messenger. Now the way is to set up
        that plausible deniability - blame a tool, blame an outsourcer, etc.
        I'll bet every manager on earth will say they never "shoot the
        messenger", but they have a million ways to duck the message or get the
        messenger to go away. It amounts to the same thing: refusing to accept
        reality. Agile will never work in a place where success = failure +
        someone to blame. There has to be a genuine commitment to succeed in the
        Agile manager. You make that point very nicely in the last paragraph.

        I really like this article - it's excellent.

        -njv
        -----------------------------------------------------------------------
        Nancy Van Schooenderwoert XP Embedded Company nancyv@...
        http://www.xp-embedded.com
        -----------------------------------------------------------------------
      • fredb001
        Great article. Thank you! ... I remember reading that the first programming language in the late 40 s was thought to signify the end of the need for
        Message 3 of 14 , Jan 19, 2004
          Great article. Thank you!

          > The belief that there will be some magical
          > incantation, tool, or facility that will kill the difficulty of >
          > software development has haunted our industry as long as I've been
          > developing software, and I remember the 60's.

          I remember reading that the first programming language in the late
          40's was thought to signify the end of the need for programmers.

          > Remember heavyweight methodologies?

          All too well. All too painfully. I'm afraid heavyweight
          methodologies' legacy is an aversion to any methodology at all. Not
          that this aversion wasn't present to begin with. But I'd say
          heavyweight methodologies reinforced it dramatically at every level
          in the organization: the programmers didn't like using them and
          management didn't like the drop in productivity.

          > Agile processes are sometimes thought of as silver bullets.

          Being a silver bullet does seem to be the chief criticism leveled at
          agile processes -- at least the opening volley. "Look at the new
          cure-all fad they're trying to foist on us." (The middle of these
          arguments is usually "It's just commonsense" and end with "Of
          course, we were doing it this way all along.")

          > The reason is the shortage of people who know what they are doing.

          Truer words were never spoken. Also, I think things would be more
          hopeful if a lot more people know, as Phil Armour might put it, that
          they don't know what they are doing.

          In particular, I hope the last four paragraphs get the widest
          circulation possible. Maybe we could all pitch in for a spot during
          the Super Bowl?

          Fred
        • Bishop, Murray
          Sorry for the lateness of this reply, and thanks for the article, which I liked. ... Maybe say and I ve been doing that since the 60 s , after all - if you
          Message 4 of 14 , Jan 20, 2004
            Sorry for the lateness of this reply, and thanks for the article, which I
            liked.

            > I don't know if other industries fall prey to the silver bullet myth as
            > hard
            > as systems development. The belief that there will be some magical
            > incantation, tool, or facility that will kill the difficulty of software
            > development has haunted our industry as long as I've been developing
            > software, and I remember the 60's.

            Maybe say "and I've been doing that since the 60's", after all - if you
            remember the 60's, you weren't there. 8-)

            Best Regards,
            Murray
          • Ken Schwaber
            I think we might get Coors to include us. Ken ... From: fredb001 [mailto:fredb001@comcast.net] Sent: Monday, January 19, 2004 10:17 PM To:
            Message 5 of 14 , Jan 21, 2004
              I think we might get Coors to include us.
              Ken

              -----Original Message-----
              From: fredb001 [mailto:fredb001@...]
              Sent: Monday, January 19, 2004 10:17 PM
              To: scrumdevelopment@yahoogroups.com
              Subject: [scrumdevelopment] Re: Comments on Silver Bullets


              Great article. Thank you!

              > The belief that there will be some magical
              > incantation, tool, or facility that will kill the difficulty of >
              > software development has haunted our industry as long as I've been
              > developing software, and I remember the 60's.

              I remember reading that the first programming language in the late
              40's was thought to signify the end of the need for programmers.

              > Remember heavyweight methodologies?

              All too well. All too painfully. I'm afraid heavyweight
              methodologies' legacy is an aversion to any methodology at all. Not
              that this aversion wasn't present to begin with. But I'd say
              heavyweight methodologies reinforced it dramatically at every level
              in the organization: the programmers didn't like using them and
              management didn't like the drop in productivity.

              > Agile processes are sometimes thought of as silver bullets.

              Being a silver bullet does seem to be the chief criticism leveled at
              agile processes -- at least the opening volley. "Look at the new
              cure-all fad they're trying to foist on us." (The middle of these
              arguments is usually "It's just commonsense" and end with "Of
              course, we were doing it this way all along.")

              > The reason is the shortage of people who know what they are doing.

              Truer words were never spoken. Also, I think things would be more
              hopeful if a lot more people know, as Phil Armour might put it, that
              they don't know what they are doing.

              In particular, I hope the last four paragraphs get the widest
              circulation possible. Maybe we could all pitch in for a spot during
              the Super Bowl?

              Fred



              To Post a message, send it to: scrumdevelopment@...
              To Unsubscribe, send a blank message to:
              scrumdevelopment-unsubscribe@...

              Yahoo! Groups Links

              To visit your group on the web, go to:
              http://groups.yahoo.com/group/scrumdevelopment/

              To unsubscribe from this group, send an email to:
              scrumdevelopment-unsubscribe@yahoogroups.com

              Your use of Yahoo! Groups is subject to:
              http://docs.yahoo.com/info/terms/
            Your message has been successfully submitted and would be delivered to recipients shortly.