Valuing Things That Break

1 Feb 2019

Admittedly, valuing things that break is very hard. Engineers hate things that break. And if a thing is broken, we consider it has no value at all. Computers and software are tools, and a broken tool is useless. Organizations are made up of people. And (lets be honest) most of them are broken. It takes a lot of effort to keep it un-broken. And there are many people whose job it is to keep it that way. And its a very hard job.

This post was inspired by a Rands article titled “Everything Breaks”.

It is up to you to make failure a competitive advantage. Failure is an opportunity to learn…When things break, you must learn completely from the failure. — Rands

It is important to value things that break, software, architecture, teams, organization, and culture, because that is where you learn the most information about what you’re doing. Not only do you learn how to fix things by paying close attention to how things break adopting this mindset will prevent a number of other problems.

If you’re making decisions based on looking closely at why something, anything, broke, you’re not going to make decisions too quickly based on emotion, politics, or hubris. When something actually breaks everyone is paying attention. There is nothing to hide, no whispers to silently work around things. Everyone is watching. If someone spoke up about thing X breaking before it broke, you better acknowledge it. Because they are watching too.

Again, this is hard. Making improvements by staring brokenness in the face is not for the faint of heart. It is a sign of maturity. Because Everything Breaks. And if you don’t believe that you’re not ready for it.

The things that break are not the mistake. The mistakes happen after they break. The mistakes happen in your response to the brokenness. Again, everything breaks — you cannot stop that. You can only control your response, you can choose to learn from what breaks, or not.

Does your competition believe that everything breaks? I doubt it. The baseline is that you’re both going to make the same mistakes at least twice. Maybe more. How ahead of the game would you be if you only ever made them twice. And then in two years, only ever made the same mistakes once? How much time, and therefore money, would you save?

#SoftwareEngineering Mistakes