When you want to know if your software is fixed, you need to check it. This may seem obvious, but the number of people who don’t bother cannot be counted. And by “check”, I don’t mean “does the fix look like it worked?” followed by “yes, then let’s deploy it”, I mean something quite different.
The crucial check to deciding whether to deploy a fix is not simply whether it works when you apply it, but whether it also stops working when you remove it. Too often, developers will have an idea of what the source of a problem is, hastily throw in a quick fix, watch the problem go temporarily away, and apply their fix to production. This can be quite a dangerous approach, notwithstanding how clever many developers either are, or think they are. And let me stress one point, this is not about how intelligent someone is, this is about reducing human errors, and is premised on the same basis as having a third-party proof-read a book before you publish it.
So, how do we go about countering the tendency for us to seek out positive reinforcement? This is actually fairly easy, and simply needs the appropriate mindset. This is also system and programming language agnostic. We need to negatively check the fix, and how do we do this? We take the fix, (which apparently fixed the problem), and back the fix out. Next and this is the crucial step, we check whether the original issue/problem reappears!
What we’re looking for is to “prove” firstly that the presence of our fix resolves the issue, and then also that the absence of our fix correspondingly and reliably demonstrates the issue. Once this has been satisfactorily demonstrated, we can reapply our fix, check again that the issue is indeed resolved, and only then apply our fix to staging or production systems.
Many people may see this as an unnecessary step, especially when they are smart, proud, and all-knowing. Usually the latter is where even the best of us get tripped up, and the simple negative double-check step described above is the easiest defense against an embarrassing commit log entry. Do it, you know it makes sense.
