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

Re: [scrumdevelopment] "Working Software"

Expand Messages
  • Peter Bell
    You Ain t Gonna Need It http://c2.com/xp/YouArentGonnaNeedIt.html
    Message 1 of 12 , Apr 29, 2009
    • 0 Attachment
      You Ain't Gonna Need It

      On Apr 29, 2009, at 12:13 PM, Morris, Steve wrote:




      Adam,

       

      What does YAGNI mean?

       

      Steve Morris

      Project Manager

      Life Division/PMO

      949.420.8834

      smorris@pacificlife .com

       

       

      From: scrumdevelopment@ yahoogroups. com [mailto:scrumdevelo pment@yahoogroup s.com] On Behalf Of Adam Sroka
      Sent: Tuesday, April 28, 2009 7:17 PM
      To: scrumdevelopment@ yahoogroups. com
      Subject: Re: [scrumdevelopment] "Working Software"

       




      On Tue, Apr 28, 2009 at 12:52 PM, Victor Olteanu
      <victor.olteanu@ gmail.com> wrote:
      >
      >
      > Could members of this group point me to some resources that talk about how
      > to achieve "working software" at the end of an iteration ?
      >
      > In my experience, this is one of the more difficult aspects to get right,
      > from a technology stand-point. I think a metaphor for it is building a
      > house, and deciding between building "one room at a time" and having the
      > 'owner' check that everything is ok with that room, or building it in a
      > different fashion so that you can see progress but you cannot really see
      > "finished rooms" until most of the work has been completed.
      >

      We have rejected the "building a house" metaphor in its entirety. The
      problem is that most of the cost of building a house is in providing
      infrastructure. You need: a foundation, plumbing, wiring, connections
      to municipal utilities, weight bearing structures, etc. All before you
      can put in walls, fixtures, etc. That make up the actual living space.

      With software there is very little infrastructure needed to provide
      useful functionality, and in the vast majority of cases what is needed
      is already there (e.g. you have a machine, an OS, any number of usable
      VMs, a browser, an internet connection, free or low cost services on
      the internet, etc.) A case could be made that many of these things are
      missing in portable or embedded platforms, but that is continually
      less and less true.

      90% of business software boils down to the same basic ideas: user I/O,
      persistent data storage, simple algorithmic calculations,
      visualization of data, network communications, etc. Most of the really
      hard parts of these problems have been solved... over and over again
      in every different language. Many of them have been solved so well
      that your new, innovative solution is actually two or more steps
      backwards. What you are really doing is just assembling these pieces
      together in a way that solves a business problem.

      > I have run many times into the argument that it would be much more
      > technologically efficient to build in a way that wouldn't allow testing
      > until a certain point in time. The result is that at the end of an
      > iteration, things that are "half-made" or "non-testable" are left, which
      > runs contrary to Agile (with a capital A) and Scrum.
      >

      It is likely very "technologically *inefficient*" to build something
      that cannot be tested until a certain point in time. The reason being
      that you don't know whether or not your solution actually works until
      you test it. The more time between when you write it and when you test
      it the more the potential that the effort (and any effort in the
      meantime) has been wasted.

      Taking that a step further, it is "technologically *inefficient" as
      well as poor business practice, to go any longer than necessary
      without presenting a working solution to a business person who can
      validate that solution in business terms.

      > Do you have experiences with these and are there any general principles that
      > can be used to tackle this problem of having testable features at the end of
      > each iteration? I understand it's more of a technology problem than a
      > management one. It also seems to me that the shorter an iteration, the more
      > "overhead" and the more difficult it is to achieve it - and I was surprised
      > to hear of situations where 1-wk iterations were used successfully even
      > despite these difficulties.
      >

      General principles:

      1) Avoid conflating technical concepts with business needs. When
      business users make technical assumptions, question them pointedly
      (e.g. you say you want a desktop UI and an iPhone app. Do you really
      mean that you need to access the app from the desktop and the iPhone?
      Might it be sufficient to have a web page that we could prove was
      usable from both?)

      2) Question your own technical assumptions and those of your
      teammates. We're going to need an MVC framework. Are we? We're going
      to need an Oracle database. Are we? YAGNI.

      3) Treat each story as a vertical slice and implement the simplest
      possible solution from end-to-end. Make the solution real simple,
      possibly too simple, possibly retardedly simple. If the first story is
      that a user fills data into a form, submits it, and gets an answer
      might it be sufficient to have a simple static page, a servlet that
      processes the form, a very simple domain model that captures the data,
      and a flat file to store the data?

      4) Once you have two or more stories that do some of the same things
      allow reuse to emerge through refactoring. In other words: look for
      elements of the solutions for each "vertical slice" that require
      similar behavior. Isolate that behavior and make it just generic
      enough to solve each problem. "Re-use" that functionality in both
      places so that there is no duplication. The key is to never design for
      reuse. Look for opportunities to avoid repeating yourself and reuse
      will emerge.

      I hope that helps. If you have more specific examples of where/how you
      find this approach difficult to understand or apply I am sure that we
      can provide additional explanation.


      ------------ --------- --------- --------- --------- --------- --------- --------- ---
      The information in this e-mail and any attachments are for the sole use of the intended recipient and may contain privileged and confidential information.  If you are not the intended recipient, any use, disclosure, copying or distribution of this message or attachment is strictly prohibited.  If you believe that you have received this e-mail in error, please contact the sender immediately and delete the e-mail and all of its attachments.
      ============ ========= ========= ========= ========= ========= ========= ========= ===
      



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