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

Comments on Silver Bullets

Expand Messages
  • Ken Schwaber
    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
    Message 1 of 14 , Jan 16, 2004
    • 0 Attachment
      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.
    • Mike Cohn
      Ken-- This looks really good to me. I d only point out that the fourth paragraph starts out with Agile processes are sometimes though of as silver bullets
      Message 2 of 14 , Jan 16, 2004
      • 0 Attachment
        Ken--
        This looks really good to me. I'd only point out that the fourth paragraph
        starts out with "Agile processes are sometimes though of as silver bullets"
        but you want THOUGHT instead of THOUGH.

        I think the reason our search for silver bullets fails, as Brooks predicted,
        is because our tools and ways of working aren't yet developed to the point
        where we'd even know what to do with a silver bullet. Think of a stone-age
        caveman who is suddenly given a bullet. It's not going to make his life any
        easier. As we've previously progressed from the stone age to the bronze age
        to the iron age we need similar progressions in how we think about how we
        build software. If pushed I'd suspect we started with the Spaghetti Age
        moved to the Methodology Age (80s and 90s) and are now entering the Agile
        Age. I'm sure it won't be the last.

        --Mike

        -----Original Message-----
        From: Ken Schwaber [mailto:ken.schwaber@...]
        Sent: Friday, January 16, 2004 8: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

        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/
      • Monique L. Attinger
        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
        Message 3 of 14 , Jan 16, 2004
        • 0 Attachment
          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@...]
          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@...
          To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...




          Yahoo! Groups Links

        • Chak
          Software is full of tradeoffs , and many times we have to choose our poison. So, yes, people need to be told that there are no silver bullets, and will never
          Message 4 of 14 , Jan 16, 2004
          • 0 Attachment
            Software is full of tradeoffs , and many times we have
            to choose our poison. So, yes, people need to be told
            that there are no silver bullets, and will never be.

            Chak.

            --- "Monique L. Attinger"
            <monique@...> 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@...]
            > 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.
            >
            === message truncated ===


            __________________________________
            Do you Yahoo!?
            Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes
            http://hotjobs.sweepstakes.yahoo.com/signingbonus
          • 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 5 of 14 , Jan 16, 2004
            • 0 Attachment

              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 6 of 14 , Jan 16, 2004
              • 0 Attachment
                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 7 of 14 , Jan 16, 2004
                • 0 Attachment
                  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 8 of 14 , Jan 18, 2004
                  • 0 Attachment
                    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 9 of 14 , Jan 19, 2004
                    • 0 Attachment
                      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 10 of 14 , Jan 20, 2004
                      • 0 Attachment
                        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 11 of 14 , Jan 21, 2004
                        • 0 Attachment
                          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.