cumulativehypotheses

One day the software development industry will be gown-up enough to talk about what we do in its own terms, but for now we have, for some reason, to use metaphors. And we love, for some reason†, transport related ones. A recent entry is the (Agile) Release Train. It’s a terrible metaphor. Here are some other mass–transportation metaphors for how you might organise the release schedule for your software development activities, ordered from less to more meritorious in respect of the figures of merit batch size, and the cost of delay if you miss one.

In these metaphors, people stand for features.

1. Ocean liner—several thousands of people move slowly at great expense once in a while. Historically, this has been the status quo for scheduling releases.
2. Wide–body airliner—several hundreds of people move quickly, a couple of times a day
3. Train—several hundreds of people move at moderately high speeds several times a day

Some failure modes of the train metaphor…

Although the intent of a “release train” is that it leaves on time no matter what, and you can get on or off at any time until then, and if you miss this one, another will be a long in a little while, in practice we see attempts to either:

• cram more and more people onto the train in a desperate attempt to avoid having to wait for the next one, à la rush-hour in many large cities, or
• add more and more rolling stock to the train to avoid having to run another one

More generally, what a metaphor based on trains will mean to you may depend a lot on your personal experience of trains. For my colleagues in Zürich trains are frequent, swift, punctual, reliable, capacious & cheap. For my colleagues in London, not so much any of those things…

4. Tram—several dozens of people move significantly faster than walking pace every few minutes

† Actually, that might be because for quite a lot of the the industrial period, say from about 1829 to about 1969, various forms of transport were the really hot technological stuff of the day.