I was in a social media discussion the other day where someone said “Perfection isn’t real, but progress is.” This started me thinking, is there really no perfection? Can you not actually create a piece of software that is perfect?

Of course you can. As long as your requirements are perfect, and the code does exactly what the requirements want, and you get everything exactly right, you can attain perfection. But let’s be realistic, perfection is rarely attained unless your requirements are akin to a school assignment that says: “Print out ‘Hello World’”

Most requirements documents contain far more than you can realistically accomplish, and modern computing is a complicated menagerie of technologies all strung together to meet complicated requirements to not only accomplish a task, report on that task, but also predict how many users will come back and do that task again one day (among other things). The concept of the MVP has taken over in the past few years, and if you haven’t heard the term, it is not as positive as the acronym sounds to any sports fan. It means Minimum Viable Product. It basically should mean to ship the minimum product that will do something positive for the customer and get them closer to that perfection they wanted.

But how do you know what the customer wants? Will you ever give them what they want if you don’t attempt to capture what their “perfect” solution would look like? This is why perfect must be a real concept, even if it is rarely attainable (and I will freely admit, rarely understood even well enough). If you don't even try define what the perfect solution is, what are you targeting? Mediocre? Just OK? Good enough?

Determining what perfect is, is a lot safer and easier than trying to nail down good enough. If you try to define your customer’s desires in the terms of “this is good enough” without getting an idea of what their perfection is, as timelines slip and features fall off, you are negotiating against what they had already said was their bare minimum good enough, rather than their actual desire for a perfect solution. So, by definition, you end up with an MVP that isn’t good enough and may not even be minimally viable. Part of defining perfection is to tag parts of the requirement as necessary versus the ideal that you are wanting from the perfect solution.

Last thing… perfect changes over time. The reason for iterative development, defining mere slices of the overall perfection, MVPs, good enough solutions, and all that is simply the problem of time. Back in the dark ages of waterfall development, people spent lots of time defining perfect, but by the time the code was being written, and certainly near that glorious final release… perfection had often shifted for one reason or another and the customer wanted something else. Sometimes entire generations of hardware and software would occur, sometimes the process was so slow the problem you were trying to solve had already failed.

Perfection is certainly achieved on rare occasions, but for the most part, it is only a hypothetical target that you know is somewhat unlikely and likely to change even if you did attempt to attain it. It is just that without that target, you are shooting for imperfection and that is a slippery slope.