The Fruits of Pain

July 15, 2008 by JurgenAppelo

I recently blogged about a little personal disaster that resulted in 100 gigabytes of data being wiped out from both my hard disk and my backup disk. Fortunately, I was able to recover most of the important data that I lost. And despite the panic of the moment I can say that I might even be better off now.

The situation after the catastrophe is better than the one before.

Reconstructing my data folders required me to rethink the folder hierarchy, to clean up old junk I never used, to improve file and folder naming, and to clearly separate vital data from convenient data. Before the crash my data storage situation was a bit messy. It wasn't bad, but it just wasn't good either. But after the catastrophe I spent a lot of time creating a situation that is now much better than before. So, why didn't I do all of that earlier? It would have saved me a lot of trouble.

The value of refactoring is proportional to the pain caused by the latest problem.

Why are buildings usually only reinforced after the latest earthquake? Why do I improve my own dental care only after I lost a bad tooth? Why do I refactor my code only after I encountered tough design problems? Why do employees only apply better development techniques after being hit on their heads with a smelly dead fish by one of our customers?

It's because value is subjective. The value that we attribute to work increases significantly after we've experienced pain. And the bigger the pain the higher we value the work that we do to prevent that pain. The value we place on work is not correlated to the value of the results, it's correlated to the value of the pain when not doing the work.

That's why people (including me) only change when they feel pain.

And that's why managers (like me) find devious ways of inflicting pain to make people change.

It hurts to be good... No Pain No Gain

Permalink