Preface
This is an opinion piece on ‘Enforceable Correctness’ - a conceptual prerequisite of designing, building and maintaining computer-backed systems.
It is short, as short as I could reasonably make it, because people who might actually benefit from reading this rarely have more than a few minutes to spare.
The following post will hinge on a few assumptions, which can be summarized as:
- Computers are used to mitigate the limited memory and operational consistency of humans.
- When a computer is used, the expectation is for the output to be correct each time.
- Poorly designed systems produce widespread workarounds that quickly trickle down into standard operating procedures.
- A good system is rarely bought, nor built. A good system is earned.
Let’s get to the good stuff.
Correctness
Correctness is a fairly simple concept. To be true - or, at least, within the bounds of what is accepted as true. A tagline that is seemingly impossible to escape within corporate IT and IT consulting is that 100% correctness is an unattainable objective. I am a firm believer in the necessity of managing expectation, but holy f*ck.
Now, don’t get me wrong, I am very much aware that there are edge and corner cases. There will always be exceptions. Much like Robert C. Martin isn’t advocating for actual 100% test coverage, I am not advocating for 100% correctness. I am especially not advocating for 100% correctness in every system, every time - because that is neither realistic nor helpful. And around these parts we try to do both.
If 100% correctness is impossible, that then poses the question:
How correct is “correct enough”?
Keep that question in mind as we continue.
Rules of Engagement
When should a system prevent an action by its user? The easy answer is, as always, “it depends”.
In some cases, you might say a system should never prevent a geniune desired action of an authorized user. One example of such a system is a GNU/Linux PC. The computer wizards of the last century declared - in no uncertain terms - that being able to´sudo rm -rf --no-preserve-root /´ is an inalienable right.
A beautiful, unconditional notion - as long as you don’t start imagining too many of the possible scenarios. As a polar opposite to this ‘free system’ doctrine, we have the ‘computer says no’ mentality - the ‘strict system’. In this model of thought, the computer determines the terms of operation, as defined by whichever group or individual that programmed it.
The ‘strict system’ model is often a requirement for more complex (maybe even distributed) systems. This does however come at a cost:
If a system is not correct enough, it can’t represent reality. If a system can’t represent reality, you’ve got a real problem on your hands.
Correct enough to enforce
Then, finally, to the title concept: Enforceable Correctness. A concept as simple as it is elusive. The job is very straight-forward, the system needs to be correct to such a degree that you can:
- Detect when a user asks something that is not allowed (usually called ‘validation’)
- Deny execution of the user’s action.
- Tell the user to get good (optional)
Inversely, if you don’t have enforceable correctness, the system cannot validate the inputs. If it cannot validate the inputs, it cannot possibly make any guarantees about proper output.
If the system you just built/bought/configured/deployed cannot guarantee proper output - it’s time to get back to the reason why we use computers in the first place.
A computer you can’t trust to be correct is quickly reduced to a damn-near useless (and very expensive) hunk of metal and plastic. Nobody wants that.