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

RE: [scrumdevelopment] Comments on Silver Bullets

Expand Messages
  • John Redfield
    I enjoyed the article, it s refreshing to view it doesn t work right from the developers point. The second paragraph seems a little stand alone , maybe a
    Message 1 of 14 , Jan 16, 2004

      I enjoyed the article, it’s refreshing to view “it doesn’t work right” from the developers point.

       

      The second paragraph seems a little “stand alone”, maybe a little more content to help it flow/transition from your opening paragraph?

       

      Nice work.

       


      From: Ken Schwaber [mailto:ken.schwaber@...]
      Sent: Friday, 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@...
      To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...



      Yahoo! Groups Links

    • Edmund Schweppe
      ... [ ... ] ... I had to think a minute about this paragraph; the phrase silver bullet usually makes me think of Fred Brooks and his essay No Silver
      Message 2 of 14 , Jan 16, 2004
        Ken Schwaber wrote:

        > I'm looking for comments on the following "article."

        [ ... ]

        > 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 had to think a minute about this paragraph; the phrase "silver bullet"
        usually makes me think of Fred Brooks and his essay "No Silver Bullet".
        Here, I guess you're saying that "silver bullets" are the things people
        *think* will magically fix everything.

        Apart from that, though, I like it. What's the target audience?

        --
        Edmund Schweppe -- schweppe@... -- http://schweppe.home.tiac.net
        The opinions expressed herein are at best coincidentally related to
        those of any past, present or future employer.
      • 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 3 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 4 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 5 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 6 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 7 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.