Imperfection

Blog | March 2nd, 2013

Software development is a surprisingly creative field. Sure, for some things there’s really only one way to skin a cat, but for the most part it’s up to the programmer’s style. It’s much more than interface design: every part of code has some kind of malleability, and that’s where the coder’s personality is readily apparent.

Some developers pursue the absolute best way of writing something, even if it means they’ll never actually ship a product. They believe in the vector—one absolutely perfect approach that is both infinitely scaleable and infinitely rigid. It never changes, but never has to. It’s the scientific equivalent of God, an ultimate truth.

The problem is that the premise is always changing. It’s as if Einstein’s equations only apply for eighteen months until the laws of physics themselves are rewritten by a new, more efficient manufacturing process. It may have been the perfect solution at the time, but ultimately you’ll end up spending too much time perfecting a popsicle in the sun.

Most developers balance their desire for a perfect solution with the more adaptable, “good enough” alternative. How long the solution works, how much work it takes, and how effective it is all depends on how many assumptions we make about the premise, about those laws of physics. Like biological evolution, the right approach is to make things mostly rigid and predictable, while leaving a few bits up to mutation and adaptation. Sure, you’ll have to go in and fine-tune your code periodically, but you’ll know that you’ve got a great answer for the current problem, not an axiom that leaves no room for tectonic shifts.

There’s no such thing as perfect code. Ship something broken, or ship nothing at all.