You Will Never Know Enough
Make peace (and progress) with incomplete knowledge
You are always working with incomplete knowledge. If you’re working on something for the first time, there will come a point in future — perhaps tomorrow, perhaps next year — when you find a better way. You may decide against the workaround you’re putting in place now. You may find a simpler way to code something. You may know exactly where to find the problem you’re hunting down. In short, in the future, you know more.
That horizon makes it sound like we can never do anything — or at least anything good — in the present. It sounds like an invitation to overthink, procrastinate or give up in despair. But this breach is where humans excel. We are always working with incomplete knowledge. We start the day without knowing what the day will truly bring — knowledge we won’t have until the hindsight of day’s end — and we get through. Although far from perfect, we’re surprisingly good at it. The issue is not so much that we don’t know everything we need to know, but that we don’t realise it — or that we fool ourselves into believing we do.
It is impossible for one to learn that which one already thinks one knows.
You can always make progress by trying something out. By trying things out you learn something, you acquire knowledge. By trying things out, you might avoid dead ends, needless detours and treacherous routes. By trying things out you might have something that works for now and, in future, can be improved, built on or replaced based on understanding rather than guesswork or panic.
But don’t forget to come back to it in future. Legacy codebases are mired in the regret of unapplied knowledge. Deferment to the future is a form of commitment rather than one of abandonment, as is so commonly practised.
We should be inspired by compassion rather than blame when we find ourselves frustrated by legacy code. The authors of the code — yourself included — most likely lacked many insights from their future we now have in our present. The inevitability of imperfection doesn’t make whatever problem we’re dealing with go away, but it should temper our frustration and make us less ready to misattribute intention.
There are more things in Heaven and Earth, Horatio, than are dreamt of in your philosophy.
Although we might identify technical debt as being the defining problem of legacy, a simple but significant omission makes this characterisation misleading: technical debt is not intrinsically a problem; unmanaged technical debt, however, is. If you’re managing it, well done! A debt is an obligation to repay and, if you’re fulfilling that obligation, that code is probably not considered with the negativity ‘legacy’ often entails.
So, if your debt is unmanaged, ask yourself why is it unmanaged? Characterising a problem simply as technical debt misses not only an important nuance — managed versus unmanaged — but also the distinction between cause and effect. Technical debt is often blamed, but is an effect rather than a cause. The question to ask is “What caused this?” The answer is typically technical neglect.
The causality of neglect is hard to see because it is an absence of a thing — care, attention, remediation, investment, work — rather than a thing that is easily observed. Inaction lacks the visibility of action. Searching for improvement becomes more a question of “What are we not doing?” than “What are we doing wrong?”
And questions are important — often more so than answers. They help us interrogate what we know, what we believe and what we want — and to distinguish between knowledge, belief and desire. The knowledge you have at the moment is incomplete and imperfect — and, for any given moment, always will be — but your ability to acquire knowledge and put it into practice is ever-present.
None of our beliefs are quite true; all have at least a penumbra of vagueness and error.
Software development (and life) is far from being a game of complete or perfect information, but that doesn’t mean you can’t play — or that you can’t play well.
