A good analogy can be a powerful tool, like a wireless, cordless solar
coffee-tamper.
I have gotten pretty good mileage out of my “[XML as
hill](http://ptsefton.com/blog/2004/07/29/xml_as_hill_2)” analogy, which
looks at the issue of complexity in document formats. Getting people to
use a complex format can be like getting a kid to pedal up a big hill;
no matter how great the view, or the ride down the other side if it's
too steep there will be tears.
I once knew someone who understood the power of analogies well. Lets
call him 'WB'.
“XML is like petrol”, he told one of his managers.
**Manager:** Oh yes?
**WB:** Yes if you don't put petrol in the car it won't go. See, that's
like XML. We have to put XML in our applications or they won't work.
**Manager:** See, you other technical people, WB explains things so
nicely. Makes it simple for me. Now I can explain to the customers why
we need XML.
(For my less technically minded readers I would like to point out that
the “XML is like petrol” analogy is crap. XML is either like a hill or a
pretty rainbow-coloured tortoise from the planet Zuurg.)
I've been wondering if there's any mileage in another analogy concerning
two things I do a fair bit of now; project management & cycling.
Lets talk about cadence, the rate at which your pedals go around.
Sheldon Brown
[says](http://www.sheldonbrown.com/gloss_ca-g.html#cadence):
> Inexperienced cyclists tend to ride in higher gears than they should,
> pedaling at a slower cadence.
>
> Most experienced cyclists pedal at cadences in the range of 70-90 RPM.
> This puts less strain on the joints, particularly the knees. Racing
> cyclists often use even higher cadences for bursts of accelleration.
> http://www.sheldonbrown.com/gloss\_ca-g.html\#cadence
So, in order to look like an experienced cyclist (hang on, I think I am)
I aim for a cadence of around 90 when I'm on my [Trek
520](http://ptsefton.com/blog/2006/02/07/new_bike:_trek_520). That is,
the pedals are going around around thrice every two seconds.
If you're going up a big hill, then you use a lower gear to keep the
legs moving at this efficient pace. Going down hill you change up to a
high gear and go faster (there are limits, though!).
More from Sheldon Brown, on different approaches; **pushing** vs
**spinning**:
> "Pushing" a [high](http://www.sheldonbrown.com/gloss_ha-i.html#high)
> gear at a slow cadence is like power lifting. It is good for building
> up muscle mass and bulking up your legs, but it does little for your
> heart or lungs, and you can hurt yourself if you overdo it.
>
> "Spinning" a [lower](http://www.sheldonbrown.com/gloss_l.html#low)
> gear at a rapid cadence is more like swimming. The rapid motion, with
> many repetitions makes the legs supple and flexible, it is highly
> aerobic, and the light pressure that goes with this style reduces wear
> and tear on the joints. With practice "spinning" becomes easier and
> more comfortable.
> http://www.sheldonbrown.com/gears.html
So in cycling the game is to **pick a reasonably rapid cadence** and
then **use gears** to keep the pedals moving at that cadence. This
reduces stress on your body, reduces the likelihood of injury, and gives
you a **sustainable** cycling experience. We try to do the same thing in
projects I'm working on at USQ ([RUBRIC](http://www.rubric.edu.au/) &
[ICE](http://ice.usq.edu.au/)). We spin, not push.
In the RUBRIC and ICE projects we use an
[**agile**](http://en.wikipedia.org/wiki/Agile_software_development)
**project methodology**. This means that in addition to performing
back-flips in our offices, we work with fixed-length work-cycles of one
and two weeks respectively. When we are working on big, hard things then
we break them into small parts and take several cycles – so we can keep
spinning. That's like using a low-gear. Many small, easy things can be
done in one cycle; like using a high gear.
We don't push on large tasks without breaking them down.
I can't prove this using any objective measure, but for development
projects like ICE, 26 MPY (meetings per year) seems like an ideal
cadence for project meetings, while on a project like RUBRIC, where we
are doing a lot more configuration and installation and documentation
than development a cadence of 52 MPY is more appropriate.
In both projects we like to keep the day-to-day tasks spinning along at
no more than half a day's worth of effort so the cadence is a similar at
that level, although again on a development project like ICE there are
more task at the larger end of the scale and in a project like RUBRIC we
have lots of small administrative tasks that don't take long.
We go for the quick cadence so we can reduce stress on our psyches.
As the Wikipedia [says at the
moment:](http://en.wikipedia.org/wiki/Cadence_(cycling))
> Some cyclists believe that some cadences are more efficient than
> others, but the wide range of preferred cadences among racing cyclists
> suggest that the difference, if any, is small.
>
> An important point is that any particular cyclist has only a narrow
> range of preferred cadences, often smaller than the general ranges
> listed above. This in turn influences the number and range of gears
> which are appropriate for any particular cycling conditions.
>
> http://en.wikipedia.org/wiki/Cadence\_%28cycling%29
****