Technical Debt is propaganda

There was a rather interesting post that popped up the other day on Hacker News. I had a few people send this to me asking for my thoughts, so I thought I'd share them. Upon reading it, I was equal parts amused and infuriated. TL;DR team negotiated a 10% time budget to work on technical debt and called that a success. Really?! 10%? That is what you'd call a successful negotiation? To do work that you probably should be doing anyway? Someone clearly hasn't realised that they are all on the same team.

A mistake that teams and organisations often make is thinking that technical work is somehow magically different from feature delivery. I've got news for you, the ability to deliver changes safely and expediently to your customers over an extended period of time predictably in a way that gives you a market advantage IS a feature, maybe not one that your customers know that they care about in the immediate, but it's a feature that gives a measurable competitive advantage. I guarantee that if you were to do focused customer research on: a product that updated frequently in a way that served your customer and didn't break, they would choose that over a product that never improves and breaks all the damn time! But research on temporally sensitive experiences is almost never conducted (and that's probably because it's hard — to test AND build). This isn't a licence to over-engineer, it's a call to actually understand what you are building. If you're building a product in an established organisation that is trying to compete in a saturated market and you have a technical backlog split out from your product backlog like so many other teams, seriously and immediately (like, right now... I mean it) evaluate what the bloody hell you are doing.

Let's call Technical Debt what it really is: a compounding history of mistakes and poor decisions made by people that aren't experienced enough to understand the lie perpetuated by people who are simply caving to pressure to deliver on another's short-sighted, reactionary agenda. The word technical debt has lulled many into a false sense of security — particularly those that are comfortable with more traditional, financial debts. These are things that eat into the livelihoods of engineers, into the dreams of product managers, and into the calendars of managers and executives.

Let's do a quick thought exercise: If a common response to not being able to deliver feature x by y date is "we have too much technical debt", but your answer to deliver feature x by y date is to cut corners and accumulate additional "technical debt", do you not see the failure in logic?

"If you can get today's work done today, but you do it in such a way that you can't possibly get tomorrow's work done tomorrow, then you lose." — Martin Fowler

Technical Debt is nothing like traditional debts. It's exponential and invisible (because a team that knew that they were about to create it would never actually do it). In researching for this post I came across this rather humorous article by Ralf Westphal where he likened Technical Debt to an "addiction". I find this to be quite an appropriate analogy even if it is a little cheeky. You build a dependency on it as your team and way-of-working adjusts to the new baseline in an effort to reach some semblance of homeostasis. In medicine, this is often explained as a down-regulation of receptor activity caused by over excitement as the body tries to adjust to a stimulus created by an over-abundance of some agonist.

Here are some things that you can do to take control of existing technical debt and your dependency on it:

1. Educate your teams on the importance of Continuous Integration and Continuous Delivery. The data are in — this is the best way to deliver software.
2. Never, EVER negotiate shorter timelines for delivering the same work with fixed resourcing. Only anxious, reactive, and immature leaders will haggle and barter with you and your team over estimations without providing additional support.
3. Better still, don't agree to timelines on delivery further out than a sprint. You can't predict the future, don't pretend you can, and don't pretend that others can either (I know a government or two that would be interested in speaking with you if you're still convinced you have this power). A team that delivers any number greater than it's cost in value should never be made to estimate their work.
4. Build a reputation of going fast, being consistent, and releasing often with high quality.
5. Know what you are building — this is so unbelievably simple, but it's not necessarily easy.
6. Structure the team and the work effectively — go all-in on Team Topologies. This is mostly a solved problem.
7. Build even small scope with high quality (that doesn't mean over engineering, it means optimising for change).
8. Always work on the next most important thing.
9. Constantly iterate and improve on all aspects of your delivery. As a software development team you are (broadly speaking) building two things: Software, and the production line with which to deliver software to customers, quickly, safely, and cost effectively.
10. Lastly, you're all on the same team. If you all know where you are going and you're aligned then those conversations about what to work on next almost have themselves.

If any of this resonates with you rest assured that this does take time. Surround yourself with successful peers that challenge you and don't let reactionary, unstable people influence your work.