15 April 2010

Prepare for Informed Improvisation

Software developers, like many mammals, are sheep-like and slow on the uptake.

We spent the better part of a decade celebrating our avoidance of Big Design Up Front (BDUF).

I jumped on the Agile Software Development hay-wagon. It was
  • liberating, 
  • professionally acceptable, and 
  • socially, much cooler,
to be Agile.


Agilists like me eschewed BDUF. Our approach to design was emergent. We programmed on the fly.

Yes we were faster. Yes we delivered.

In some cases we moved software into production more frequently than the Milkman delivered milk.


The question I ruminate over is
Did we deliver lasting value?  
The cows are still grazing, but I for one, contributed to several steaming cow pies in the name of agile software development.

The voices I respect in our community suggest we're avoiding the fruits of experience design considerations at our peril. Sorry Milkman, but delivery isn't everything.
Software Delivery is the milk jug, NOT the experience of gulping cold, fresh milk
There are signs our community is moving beyond the ominous clouds of Deliverence - pun intended - toward reasonable preparation & design discovery.

Building Benches

Design is premeditation. It is never an immutable concept. It is never written in stone. Ideally, my premeditations grow with me into active (perhaps subconscious) meditation during execution whether programming or building benches.

Last weekend I built a cedar bench. Much thought was devoted to who would be sitting on the bench BEFORE I cut wood. I considered comfort and aesthetic appeal. I chose a height of 19" following simulated user acceptance tests. I made a sketch. I thought about the materials in the context of human contact (choosing naturally rot-resistant cedar over treated lumber).

Our golden retrievers Lucy & Libby seem to be turning their noses up at my handiwork, but my family likes it. I had premeditated design considerations, but allowed myself the freedom to adapt on the fly.  

For me, these up-front considerations, design, or call it what you will, are no more than sound preparation.

Sound Preparation

Sound preparation is not the same as BDUF. I prepare to build something with the tacit understanding I will adapt as the unforeseen emerges.
Sound preparation allows for informed improvisation
Like performers, well-prepared programmers are freer to improvise because preparation considers eventualities - not all eventualities, but some. Preparation frees us to be creative without mucking things up, even if all we start with are a few baseline considerations like
  1. Who's going to use it?
  2. What do they need?
  3. What do they like or dislike most?
I want to be open to discovery. I want time for up-front user research. I want time to respond to user feedback. I want clear and verifiable benchmarks of value. I want enough information about users and benchmarks of value to allow for informed improvisation once the building commences.
Posted by at 4/15/2010 01:37:00 AM
Labels: , , , , ,

6 comments:

  1. Sound preparation resembles "aim high" driving strategy. When I settled in Australia (long time ago) the driving instructor whom I hired told me to "aim high", ie. always look ahead using your peripheral vision as far and as wide as you can see but don't focus on a particular object far ahead, don't deal with the details now. Just 'see' a cluster of children 200m ahead getting out of school but don't 'watch' them for now (they are still far away.) I think it is also embedded in our survival strategy to be just aware of things ahead as a cloud. They would be gradually pushed up in the priority stack and they get less blurred as we approach them. This allows us to use our energy efficiently, simplifies our planning and also allows us to proceed in an ordered manner as opposed to disorder and chaos. This might be the reason why we have evolved to have perspective vision at the first place!
    ReplyDelete
  2. I like the performer analogy you used. But unfortunately you started with the construction analogy; this just raises my hackles! Nice dogies.

    I'll bet you only built one iteration of the bench, maybe two or three. In construction the build phase is the one where most of the energy, cost and action is; it is the most obvious phase.

    In software the build phase takes the CI system about 30 sec. and happens 100s of times, cost next to nothing. All the action and energy is in the Design phase. The interesting difference is that in SW we use a deconstruction phase (about 2 sec.) after every build/test cycle except the last. This phase cost nothing, but allows for the flexibility that you desire.

    If you could get your bench deconstruction phase to 2 sec. cost nothing and have a 30 sec. build phase you could iterate constructions. In 10,000 hours you would be a master craftsman; like Sam Maloof.
    http://agilecomplexificationinverter.blogspot.com/2009/09/methods-of-work.html
    ReplyDelete
  3. Hey Ergun,

    Aim High is a slogan used by one of the branches of the US military. Once I clear my head of that cloud, I like YOUR story of Aim High. I practice that driving, but didn't have a name for it.

    Bottom line of this post is that developers tend to jump right into coding before we've prepared. The agile paradigm has us focusing too much on delivery. So, we jump into coding right away so we can demonstrate the silly notion of velocity. I DO like the cadence of iterative development, but I’m seeking to incorporate things like usability, understanding users, and understanding how to create verifiable and lasting value.

    Cheers,
    Bob.

    PS - I dig the Feynman quote and I enjoyed your lasted post "Infinite Onion" on Negative Matter http://negativematter.blogspot.com/2010/04/infinite-onion.html
    ReplyDelete
  4. Hey David (aka, ^{)} Koontz),

    Oh man! You're right, I mixed analogies. I hate that too. Makes me want to re-write.

    Construction is not a good fit for software is it?

    What I was trying to emphasize is the need to spend time up front on usability (bench height & non-toxic materials) considerations before cutting wood. Often in the agile space, we jump right into cutting wood.

    Anyway I like the idea of improv, but it's usually preceded by preparation and practice. The two analogies collide here.

    Cheers,
    Bob

    PS - Cool "Methods of Work" post on your AgileComplexificationInverter blog http://bit.ly/aci0Dd. Thanks for pointing that out. A Method of Work I want to experiment with is ways to verify that we're providing better stuff with each iteration and NOT just finishing tasks. Agile measures speed, but not value.
    ReplyDelete
  5. Great post Bob! I totaly agree....
    When it comes to analogies, I think a maybe "more" proper driving analogy is the way you plan your car holiday trip from for example Stockholm to the French Riviera. You have to decide what you need to pack before you go on the trip (sun block, short. Sunglasses etc). You also have to look at the map before you go and you have to decide which route to take, however you will run in to traffic jams, get a flat tire, find road blocks or even decided that a stop in Vienna is better than the one you have planned in Munich. There for it is very good to be agile on the way to your target destination. Nevertheless without an over all plan from the start you might end up in the Swiss Alps instead of French Riviera, and since you did not bring any skis or warm closes you will have to pay for them when you are at the destination, and everyone knows how expansive it is to buy stuff in Switzerland. Also it might not be too bad to have a holiday in the Swiss Alps, but if you wife wanted to go to the French Riviera you are in big trouble ;-)

    Kind regards
    Anders
    ReplyDelete
  6. Thanks Anders. Your hypothetical trip sounds like one my wife and I would enjoy :-)
    ReplyDelete

Subscribe to: Post Comments (Atom)