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.
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
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.