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

RE: [scrumdevelopment] Comments on Silver Bullets

Expand Messages
  • 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 1 of 14 , Jan 16, 2004
      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 2 of 14 , Jan 16, 2004
        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 3 of 14 , Jan 16, 2004
          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 4 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 5 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 6 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 7 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 8 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 9 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 10 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.