Forget technical debt
28 points by BinaryIgor
28 points by BinaryIgor
Proposed better title ideas (to remove the first few paragraphs, meandering and time-stealing):
Great read. A lot of technical debt I've seen is really "product pivots" of various intensity.
Eg, product A sets out to do X. Turns out that users actually don't like X but really engage with one particular feature.
So you start building for that feature. But it doesn't map well to the data model of your product. You ship a load of hacks to get it working. Before you know it you've got a load of "technical debt".
A classic one I see is when someone builds a product, then it ends up that it doesn't get much direct traction, but people want to whitelabel it.
This is why I really like the cognitive load part of the article. Dealing with a whitelabeled platform with probably some level of customisation for some clients for me at least adds a whole new dimension of cognitive load. Everything gets n times more difficult (testing, releases, etc).
Agreed; in the cases you describe though it is really hard to avoid these issues - chaos happened somewhat organically and it is hard to see how it could have been avoided, since initially this thing was supposed to be something else entirely! Maybe in these cases rewriting the solution from scratch is the answer? But rarely there is a budget and risk tolerance for that!
A very thoughtful article. Recommended.
I'd like to describe it a little, because the title does not do it justice (as Uwe, the author acknowledges). My description is deliberately loose in places; I’ll mark those with (*). Also, I’m only summarizing the questions and structure; do read the article for the answers.
So the author starts from technical debt, and after finding ‘what is it?’ a somewhat fruitless approach, asks ‘what does it do?’(*)
What does technical debt do? It hurts.(*) Very well, how does it hurt? So they get a bit more specific about how the hurt manifests — and then they turn around.
‘These painful things,’ they ask, ‘what else causes them?’ Suddenly the little branching tree of ‘technical debt causes X, which causes Y and Z’ acquires a fan of roots.
They spend some time looking at some of the new roots of the problem tree — in detail, and concretely, like the rest of the essay. And then they note that discussing TD often crowds out these other topics.
Which brings us to the final sections, titled ‘Why do we limit our perception?’ and ‘Now what?’
By now you probably know whether the article will interest you. I personally recommend it, but I said so already :) Bedtime, logging off now. Good night!
I first misread the title as "Forgive" technical debt, which I'd be coming in like "omg yes" (for that, I'd just accept some things are not going to change and close as won't fix. like with the finance analogy, if you have a 1% loan... probably not worth paying that off early, just let the debt ride as long as possible and you actually end up ahead!).
But nope, that's not the title, the content is more about giving a reasonable definition and getting to causes. Pretty decent article overall, I agree with focusing on the result. The way I like to define tech debt is something you pay interest on; a decision that leads to additional ongoing effort in the long run, and this article being even more specific with "implementation effort creep" and "runtime stability detoriation" are solid. I'd add that it is really important to remember the users' time, not just development or operations or whatever.
However, I do have one point I want to push back on. The author lists one cause of tech debt as:
Extremely tight deadlines forcing developers to compromise quality
Certainly true sometimes, but tbh my experience has often been the opposite: extremely loose deadlines letting developers goof around with experimental toys or architecture astronaut nonsense and other symptoms of second system syndrome leading to a monstrosity you have to deal with later. The text mentions "overly complex architectures" and "poorly written requirements", but frankly, giving developers more time has a decent chance of making this worse, not better.
It is so important to remember the users. Software is supposed to help other people do their job. Management needs to take an active role to keep the developers on target and keep up the tight feedback loop with reality. https://www.youtube.com/watch?v=NnP5iDKwuwk
Yes! Unrealistic, too tight and aggressive deadlines are harmful (too much stress), but no deadlines or extremely mild ones can be just as bad (no stress at all), if not worse, for the reasons you describe as well as the human nature - we are naturally lazy and tend to postpone things, deadlines keep us in check, they are very useful and healthy. I would also add developers competency and internal motivation as dimension(s) - there is a large discrepancy in the degree people care about their work quality, almost irrespective of the incentives structure they currently happen to inhabit.
This is a nice systems thinking decomposition of the problem.
I love it! I feel like I had already tacitly grokked his conclusions a while ago, but it's wonderful to see it written out so clearly.
For instance, when I get pulled into a project and they say, "We have too much technical debt, how do we minimize it?" I don't immediately think, "Let's look at this technical debt!" but rather, I think things like, "What does automated testing, CI/CD, bug triage/reporting (+ pairing? PR review?), and time-to-deploy look like? What does the product -> design/UX -> engineering cycle and communcation pathways look like? How often does product change their mind, and what does that change process look like in practice (even if it is implicit/'structureless')? How are engineering/architecture decisions made and recorded? What does developer satisfaction and DX and devops look like? How strongly/weakly do the engineers/PMs/QA have a shared understanding of what it is they're trying to accomplish?" It's a bit Theory of Constraints-ish, in that sometimes there's a glaring bottleneck or two.
But we also need to broaden the picture. We need to make clear what else affects implementation efforts and runtime stability. We need to discuss more holistically what is needed to improve the situation. We need to create awareness of how certain kinds of decisions and habits have counterproductive effects.
I am not a capital-A agile type ("Use MY PERFECT METHOD® and buy my book!"), but holistic discussions (including groups broader than just the engineering team from time to time) to figure out how to improve the situation is, in my mind, the whole idea behind retros: identify pains (and wins), spitball/solicit solutions, translate into action items.
Edit, I was a bit hasty to say that's the whole idea behind retros. There are some other valuable purposes, like milestoning, venting, risk-surfacing, and temperature/dynamics checks (sniffing out power plays/hierarchies or cliques, spotting long-standing unresolved personal or technical disagreements, etc).
I think that the author wandered a little. Technical debt is measured in lines of code. We can estimate how much technical debt our employers have accrued by estimating how much code they claim to own and manage.
Can you elaborate? According to you then, all lines of code constitute tech debt, which is confusing and hard to see what we can do with that definition in practice
all lines of code constitute tech debt
This is the brutal truth, though. Every line of code is a responsibility. Even if you never change the source, you have the responsibility to stay on top of keeping things compiling as tools drift, ensuring no library dependencies have vulnerabilities, etc.
Reducing the amount of code under one's control will reduce the amount of maintenance that one must do. The less code we have, the less maintenance we do.