Pagina's

Wednesday 8 June 2011

Keeping entropy at bay (How scrum deals with Murphy)

The 2nd law of thermodynamics states that entropy (disorder) will tend to increase over time in any closed system. This is not only a law of chemistry but of physics and information too, and we know it intuitively; nothing lasts forever.

This does however present some problems, predicting as it would seem to, the heat death of the universe, and flying in the face of the highly ordered state of life on earth. Luckily we don't have to answer any of those great questions in this humble blog, although I will come back to the subject.

What is a closed system? Well, in effect there is no such thing (except perhaps the universe itself), and at the same time we can treat pretty much any identifiable system as approaching a closed or isolated system. Take yourself dear reader; you are a highly complex (low entropy) system, identifiable as distinct from your environment (relatively high entropy), and yet dependant on it to stay ordered. Should you be truly isolated from your surroundings (unable to extract and consume energy or dispose of waste), your system boundary, so to speak, would quickly fail. Otherwise, as you are a system approaching isolation, time will do the trick, eventually. This is also true of software projects.

Of course, disorder can also arise spontaneously, as Murphy said; anything that can go wrong probably will. The more leeway you give Murphy the greater his opportunity to strike. It's in that leeway and how it's organised that scrum, and agile approaches generally, differ from the waterfall model. The waterfall tries to keep Murphy out, scrum (with XP) builds feedback in at every level, so that Murphy is kept on a short leash. This neutralises damage early while maximising learning. A scrum project, staffed by cross-functional teams, is also enmeshed in its environment, minimising isolation thereby resisting increases in entropy.



The waterfall invites entropy by the very means it employs to combat it. Each phase of a waterfall project is both long lived and isolated. That means that the requirements documents have necessarily 'decayed' somewhat by the time the requirements gathering phase is completed. Pushing the requirements through the contract-negotiation pipe to the design phase will also introduce turbulence, raising entropy some more. By the time the design phase is nearing completion the requirement set will be a veritable paradise for Murphy. When the development phase finally starts, isolation is reaching its zenith, the programmers don't know who the client is and entropy is spiralling out of control. Many waterfall projects end in heat death.




Speaking of heat death, here's my two cents on the great questions mentioned above - if we assume there is no such thing as a (truly) closed system, there is no problem of the 2nd law; if there are no closed systems, the universe must be infinite in time and space, an unending soup of boiling roiling big bangs and even bigger crunches. A seething mass of bangs within bangs within bangs, bumping into and off of other bangs, each bang spawning its own black holes, which accrue galaxies over time, which collapse into ever more massive black holes, which might eventually become crunches, every black hole a potential seed universe, and so on...

No comments:

Post a Comment