There is an important concept in software development called Technical Debt.
Technical debt is incurred whenever a quick fix is implemented that solves a problem but not in the most long-term optimal way form the perspective of the whole system.
When you are building something fast, trying to get it working and ship it out, you inevitably incur a lot of technical debt. It is just not possible or right to solve every problem by re-architecturing the whole system to elegantly handle each exception at the highest level. You patch in quick fixes and things that just make it work. But at some point you need to repay your debt for the long-term sustainability of the system, otherwise it risks collapse under the weight of the technical debt.
There are a lot of analogies to this in the world of finance and investing:
- Ever cracked open new excel sheet to do a few calcs and change a few variables because your main system couldn’t immediately do exactly what you needed?
- Ever taken a one-off decision to rebalance a portfolio, sell some equities or otherwise react to market movements in a way not strictly codified by whatever investment process you were following?
You just created technical debt. Absolutely necessary in some cases to move you forward, but the key thing to remember is that at some point you have to focus on paying down your technical debt. Otherwise you’ll end up with a proliferation of one-off fixes and scraps of working that don’t add up to a high-quality operating model.