Perfection vs. Precision

Introduction

This post is the twentieth part of a ramble-rant about the software business. The current posts in this series are:

This post is about the semantics of quality.

There’s a Difference

Communication is important in every aspect of business – life too, for that matter. A common complaint is “software developers are perfectionists”. Managers rarely come out and say that, opting instead for the more fashionable “Good is the enemy of great.”

The Middle 80

If you’re aiming for the 10% – 90% market, this is certainly true. If you want to be able to plug-and-play developers like you would assembly-line workers, this is a time-proven strategy. But those jobs are all but gone from technical fields, and are disappearing from emerging economies.

Truth be told, successful software development shops don’t operate like this. There is a direct correlation between companies tha produce innovative software and companies that are cool places to work. The same applies to teams within those companies. In fact, you will see great and innovative software from a great team at a very uncool company. I experienced this while working for Brain Knight (Blog – @BrianKnight) at a company that shall not be named.

Where Are You Aiming?

If you are aiming at the middle, you will undoubtedly hit it. Why would anyone want to aim lower than the stars? Well, aiming low is one interpretation of the consultant’s mantra: Under-promise, over-deliver. It’s also safer. If you aim low and deliver big, you look like a rock star.

But this negates the value of failing. Too many people underestimate the value of failure. You are not truly free to succeed until you are free to fail. Aiming higher creates an opportunity to fail. And, every now and then, you hit your goal. Then what? Celebrate!

Semantics

When I find myself stretching to meet some goal – especially if that goal is delivering quality software – I am not practicing perfectionism (this is a good read, by the way); I am practicing precision. My goal is stable, relaible software that exhibits expected and predictable behavior. Errors are reproducible and repeatable, error responses follow a carefully-crafted design pattern, as do logging and externalization.

These patterns won’t evolve naturally. These patterns have to be cultivated. I’ve seen this implemented by architects, managers, and architect-managers; and I call it organic software management (look for Software is Organic, Part 2, coming soon…)

Conclusion

Excellence is its own reward. This must be balanced against diminishing returns, but managers often err on the side of caution long before diminishing returns begin.

:{> Andy