If you ever worked in IT or did some software development, particularly in a large organisation, there is a good chance there was a fixed delivery date driving you work. A deadline set in stone several months in advance often driven by an arbitrary decision based on factitious estimates and supported with an unrealistic dose of optimism.
It shouldn’t come as a surprise then, that the date comes and goes by and another solution is deemed delivered “late”. Rarely though with the catastrophic circumstances implied by the urgency and precision of the deadline. It’s astonishing that despite all the past experience we still insist on using a language of certainty when it comes to long-term planning of software development efforts. It seems to also stand in contrast with our experience in other areas of everyday life.
Walking to the train station the other day I have noticed this board.
Thinking about all the deadlines and fixed delivery dates and set in stone releases I looked at the train arrivals. The board clearly indicates the scheduled times and complements that information with the “expectation” of its accuracy.
For trains, that run on fixed tracks, with known routes, tried and tested hundreds of times before, in the span of an hour or so, we clearly understand the inherent uncertainty in the fixed timetable.
Why is it then so much harder to understand, appreciate and react to the inherent uncertainty in software development?