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

RE: [leanprogramming] Does agile *cause* rework that is waste?

Expand Messages
  • Rob Myers
    Allow me to squash a few lingering misinterpretations that have arisen from things said in the agile/XP community over the past decade. I know that these are
    Message 1 of 35 , Feb 26, 2008
    View Source
    • 0 Attachment

      Allow me to squash a few lingering misinterpretations that have arisen from things said in the agile/XP community over the past decade.  I know that these are misinterpretations because they were clarified for me ten years ago.  In 1998, during my first XP project, we asked about these and other comments or practices put forth by Beck, Cunningham, Jeffries, et al.  The misinterpretations linger, I think, because we all subconsciously know that transition is painful.  Better the pain you know than the mysterious pain of an agile transition, I suppose?  Rest assured, true agility brings about useful, quality software.

       

      “Do the simplest thing that could possibly work” – Not the simplest activity for the programmer!  The simplest design.  Also, there was a presupposition that programmers knew good OO design techniques and design patterns.  One big long method may seem like the simplest design.  It probably isn’t.  (That would be the “stupidest” thing.  :-)  And here’s why:  The simplest and best design is the design that can readily be altered and enhanced in unpredictable ways.  Also, this design needs to live only until you prove that it’s not sufficient via another unit test.  Two minutes, tops!  More than that, and you may be over-thinking (or, more importantly, under-testing).  TDD is a game you play with your own brain:  Prove you need it, then build it.  Look for an opportunity to simplify (based on what you have, or based on what you next want to test).  Then repeat.

       

      “You Aren’t Gonna Need It” – True, until you do need it.  Again, you know what you know, and you are playing the TDD game to prove it to yourself and to leave a trace of that analysis activity (a unit test).  If, in the prior two minutes, you didn’t build a hierarchy you know you need (note, I said *know*), you can either write the next unit test for the factory, or refactor so you have an abstraction and a single concrete class, then build the “other” of that abstraction, then test the factory.  Where is the wasted re-engineering?  People find TDD to be faster.  That’s because (I got this from Amir Kolsky) TDD pins down the behavior, while leaving the design fluid and flexible.  In other words, I can reshape my design without losing ground.

       

      Note that I keep mentioning a factory, and a unit-test for the factory:  Scott Bain and all of us at Net Objectives strongly encourage you to *encapsulate construction*.  (This does *not* imply – as was stated earlier on this board [in another thread], that you must never have a public constructor!  Such black/white statements are the very thing that cause these weirdly simplistic and legendary misinterpretations.)

       

      We can never stop thinking.  (Oh!  I said “never!”)  Agile is about responding to the present situation and information (and code), rather than attempting to predict the future.  There is a very good reason why the very good agile coaches of the late nineties were already insisting that people learn about the emergent nature of patterns while they were learning about agile principles and practices.  The two are inseparable.

       

      From: leanprogramming@yahoogroups.com [mailto:leanprogramming@yahoogroups.com] On Behalf Of Raoul Duke
      Sent: Tuesday, February 26, 2008 2:32 PM
      To: leanprogramming@yahoogroups.com
      Subject: Re: [leanprogramming] Does agile *cause* rework that is waste?

       

      > As far as I remember, the original context was a manager responding to

      a
      > presentation on Agile with "yeah, but isn't all that rework
      waste?"
      >
      > So I think the answer actually is "there is no extraordinary amount
      of
      > rework in Agile".

      Not sure if I'm gonna make a relevant comment or not, but... The two
      extremes seem to be an interpretation of You're Not Going To Need It
      where you never abstract anything vs. abstracting everything into
      space a la Spolesky's criticisms of Architecture Astronauts. There is
      perhaps some connotation that Agile is the former and classic
      Waterfall is the latter. When, of course, the best thing is somewhere
      in the middle and actually requires experience and effort to dial in
      just right for your particular project.

      So, anyway, the rework may or may not be a waste depending on what
      that rework is, and why it was done. :-)

      sincerely.


      ______________________________________________________________________
      This email has been scanned by the MessageLabs Email Security System.
      For more information please visit http://www.messagelabs.com/email
      ______________________________________________________________________

    • Gary Brown
      Hi, Alan, After reading through this thread, I am wondering if you understand Simplicity, the way Kent intended. You get simple code through TDD
      Message 35 of 35 , Feb 27, 2008
      View Source
      • 0 Attachment
        Hi, Alan,
         
        After reading through this thread, I am wondering if you understand Simplicity, the way Kent intended.  You get simple code through TDD (Red->Green->Refactor) and YAGNI.  You get low coupling, high cohesion, less redundancy, and conformance to design patterns through BDUF.  Teach people TDD, and they will understand simplicity.  You're not trying to create your own brand of XP, are you?  8^)
         
        GB.
         
         
        ----- Original Message -----
        Sent: Wednesday, February 27, 2008 2:54 PM
        Subject: RE: [leanprogramming] Re: Does agile *cause* rework that is waste?

        Ilja:
        I'm not saying this is true for you. In training thousands of
        developers, I'm saying many more don't understand simplicity at the
        level you obviously do than understand it. I can teach qualities a lot
        easier than I can teach simplicity. If someone gets simplicity at the
        level Kent and Ron and you get, no problems. We'll come to the same
        answer. But I'm having this discussion from an educator's role - how
        can I get others to get this - not how do I get this.

        Alan Shalloway, CEO, Sr. Consultant
        Net Objectives, Gold Level Sponsor of Agile 2007.
        425-269-8991
        Integrating people, process and technology through training, coaching
        and consulting.
        See http://www.netobjec tives.com/ courses/index. html for our list of
        nationally offered courses in Lean Software Development, Scrum,
        Requirements, OO, Design Patterns and TDD.
        Blogs and podcasts http://blogs. netobjectives. com/

        -----Original Message-----
        From: leanprogramming@ yahoogroups. com
        [mailto:leanprogramming@ yahoogroups. com] On Behalf Of Ilja Preuss
        Sent: Wednesday, February 27, 2008 12:14 PM
        To: leanprogramming@ yahoogroups. com
        Subject: Re: [leanprogramming] Re: Does agile *cause* rework that is
        waste?

        Alan Shalloway wrote:

        > 1) what simple means appears self evident so it is harder to have a
        > Socratic discussion about it (I never argue code qualities, but simple
        > often turns into that)

        Mhh, don't share that experience.. .

        > 2) many people misinterpret some of the qualities (many people think
        > encapsulation means data hiding)

        I don't see how that's an argument *against* "simple"...

        > 3) simple is good (in the sense kent meant it) because it results in
        > good code qualities - so why not talk about them directly

        That's not really a reason, is it?

        > 4) you can more easily discuss how to get code qualities than you
        can
        > simple code (meaning practices are easier to discuss in terms of code
        > qualities)

        That's absolutely *not* my experience. I find Kent's rules on simple
        code to be more actionable than anything else I've found about good
        code: write tests, see what ideas are in the code that aren't yet
        expressed and express them, look for duplication and remove, and don't
        write code that isn't needed yet. How much more concrete can it get???

        Puzzled,

        Ilja

        Yahoo! Groups Links

        ____________ _________ _________ _________ _________ _________ _
        This email has been scanned by the MessageLabs Email Security System.
        For more information please visit http://www.messagel abs.com/email
        ____________ _________ _________ _________ _________ _________ _

      Your message has been successfully submitted and would be delivered to recipients shortly.