Peter Chamberlin

Software meteorology

Predicting projects like the weather,

Like a lot of developers I get lost for words when trying to explain estimates. The “cone of uncertainty” helps to some extent, but I’ve always struggled for neat metaphor that stakeholders will grasp.

This morning it occurred to me that estimating software development is a bit like forecasting the weather.

It can be done reliably to an extent but things are always uncertain, even in the short term. No matter how much analysis you throw at it. The difficulty of estimation grows exponentially as you look further into the future.

The horizon for accurate weather forecasts remains around a week. Long range forecasts might extend to a month and are vague. Only extremely broad trends are predictable beyond a couple of months.

In meteorology this is because of the vast number of variables involved, and the same is true of software development. There are all sorts of things that are outside of the control of the forecaster in both cases.

With the weather we can talk about ocean temperatures and currents, the jet stream, el nino and so on. But what are the variables of software development?

I suppose you could start with:

  • The number, nature, and status of external dependencies.
  • The number and nature of touch points with existing code.

I could go on, but you get the idea.

Even so there is the nagging thought that development should be deterministic. Things should be quantifiable ahead of time.

Instinct tells us we have complete control of software. Unlike the weather we do, but even a seemingly straightforward new-build project is so complex that to it cannot be fully known by any individual without building it. So for all practical purposes it is out of our control.

The only way to complete analysis of a piece of software is to complete the software. Along the way you find out what could and couldn't be done, and how.

I wonder if a set of weather analogs would help with software estimation? Would estimating the meteorological outlook of tasks help?

A task with low uncertainty might be described as “sunny”. One with many unknowns might be described as “stormy”. One likely to run into blockers might be “frosty”.

They could be combined where not contradictory. So you might have a “sunny, frosty” task, one which is fully understood but which has unresolved dependencies.

I expect some bright mind has recorded (and dismissed?) this idea in the past but this is my take in any case.

I would be really interested to hear your thoughts on this so please get in touch on Twitter.

The animation at the top of the page is an SVG + JS thing I hacked up, loosely based on the BBC Weather icons. I uploaded the code to this pen, so feel free to hack about with it yourself.