The chaotic diver

This starts with a diving story. I will call our diver Brad. Everything about his diving was chaotic. His equipment was a mash up of the cheapest possible used kit from eBay. None of it was serviced. Everything that could leak did leak. Bits were falling off all over the place. Nothing fitted properly. If he ever had any good kit, it would have soon been reduced to a similar state to the rest of his diving wardrobe.

Underwater he crashed and bounced around all over the place. He was always on the verge of going out of control, but never quite loosing it completely. No one wanted to be his diving partner. We had to draw straws. Whilst Brad bumbled along in blissful ignorance of danger, whoever had drawn the short straw spent their dive in terror of having to rescue him.

Years of practice at not quite dying

We have a term for the cumulative effect of mishaps called the incident pit. It refers to the accumulation of minor mishaps that edge you closer to major incidents, with the pit growing steeper and harder to escape as you slide further in. Brad was orbiting the most precipitous part of the incident pit without actually tumbling past the point of no return. To quote Terry Pratchett, our diver had "years of practice at not quite dying".

Its not just divers

Which brings me back to software projects, web sites and developers. The incident pit concept is not restricted to diving. It can be applied to many endeavours including web development. 

Some developers are the keyboard equivalent of our diver. Everything is a disorganised mess. Their code barely works, but works just about well enough to scrape by without complete collapse. It just about holds together. Projects limp to delivery with plenty of 'quirks', but none are sufficiently buggy to prevent delivery. They keep doing this for one project after another. Projects that orbit on the brink of disaster.

Staying out of the pit

Applied to code:

  • Be organized – Chaos breeds problems. Structure and order help keep you out of the incident pit.
  • Keep your code organized – Clean, readable, and modular code is the foundation of stability.
  • Invest that little bit extra to do everything properly – Skimping on quality costs more in the long run.
  • Clean up when you finish – "The job is not finished until the cleaning up is done".

Funnily enough, the same principles keep me out of trouble when diving.

Topics and Tags
Discussion

If you would like to discuss any of these thoughts, please start or continue a thread on the Concrete CMS Forums.

In "The Last Hero", Terry Pratchett wrote of Cohen the Barbarian and the Silver Horde as having "years of practice at not quite dying".