The Problem with Precision

I think engineers are interesting people… especially software engineers. Given what I do for a living, I get to work with a lot of software companies, and that means I get to spend time with a lot of software engineers. If you spend enough time, in enough software companies, with enough software engineers, some patterns start to emerge.

One of the patterns that I see quite a bit is that software engineers like things to be really precise. Being precise is a good quality for software engineers… it helps them build software that doesn’t break. Sometimes broken software kills people. The problem with being precise, is that it sometimes creates a tendency to want to know everything before we are willing to do anything.

Sometimes the level of precision necessary to build a system isn’t the same level of precision necessary to understand requirements, or to do a high-level design, or to estimate a project, or to know when a system is going to be done. Sometimes directionally correct is good enough. I realize that knowing the difference is a big deal and I’m not minimizing that.

I think though that recognizing this tendency is an important first step to making progress… and not letting that innate need for precision prevent us from taking those first critical steps forward. For many problems… understanding the requirements, or the design, or the estimate, or the date in a directionally correct way is good enough.

Once we get close enough, we can make trade-offs to the requirements, or the design, or the estimate, or even the date to make sure we can deliver what needs to be delivered. Precision isn’t always necessary to start… sometimes directionally correct is good enough.  Sometimes directionally correct is all we’ve got, and maybe even all we are ever going to have.