I want to talk about technical debt. In my experience, technical debt can incur some degree of pain or perhaps even guilt stemming from the past decisions that resulted in the debt.

I talked about the risks associated with Move Fast and Break Things in my post about agile vs FDA, where this behavior can result in technical debt. My conclusion, having experienced this more times than I care to admit, is that there is a need for a sense of responsibility and integrity with regard to handling technical debt in the same manner we approach financial debt. It is not within one’s integrity to take on financial debt if there is a risk of not paying it off. It would also be ill-advised to take on financial debt if there is no plan to maximize the value from the investment.

To continue with the analogy, I’ve seen mature software development teams approach technical debt in the same way a teenager might with their first credit card. I’ve rarely seen software development teams approach decisions relating to technical debt in a mature manner. It usually manifests in the form of a proverbial can kicked down the road because there isn’t time to deal with it along with a dream-like perspective that it’ll be fully addressed in the future. That feels a bit like if I can just buy that thing, everything will be great followed by a struggle to make the payments.

To be clear, I recognize that there are perfectly valid situations where it just isn’t possible to do something in the optimal manner and that compromise is necessary. That is not what I endeavor to point at.

What I do want to point at is the notion that underneath there isn’t time is often we don’t know how or we don’t have a plan — its rarely the case that there isn’t time, it’s that we don’t make the time, we don’t think its important enough. It certainly has been my experience, and I’m specifically referring to situations where I’ve contributed to the incurring of such debt. I was in too much of a hurry to get something out the door. Once a feature is out there, it’s really hard to take it back. This adds up over time, resulting in a future where simple functions take much, much longer than they should to ship.

Side note: in my not-always-humble opinion, throwing AI at this problem to make things go faster is actually going to have the opposite effect, but that’s a topic for another day

My commentary on the pursuit of features in Building What They Need vs What They Want applies here. One impact of which is insufficient time to plan the investments being made that lead to not knowing how or not having a plan.

I recognize I’m being idealogical here. Again, there are solid reasons for having to take on the debt. My point is, take on the debt intentionally rather than in the manner a teenager might use their credit card recklessly. Strike a balance between large investments, small investments and addressing debt, always.

Here are my recommendations:

1. Balance your R&D capacity between large investments, small investments and debt retirement
2. Track those investments over time and see how you measure up with your intentions
3. Ensure time for discovery, planning and team alignment with equal importance to the development itself
4. Use a scoring mechanism for investments where the mechanism and the scores are known across the business, in order to train the business on the need for balance
5. Cultivate a broader, shared understanding of the strategic and technical vision so that the planning gets easier with more people sharing the load (this is where eschewing documentation in the interests of valuing people and interactions can be an issue)

Technical debt is always going to exist. Compromises are necessary in order to get the job done (some guy said real artists ship, which seems relevant), but be intentional about it. Align the business around those intentions, which will lead to maturity and therefore consistency.