Hacker News Reader

Comment by fn1 | Hacker News Reader

We should stop calling it "technical debt". That word suggests a clean account that can be paid off from time to time.

Instead let's call it "technical clutter", because that is what it is.

It's the equivalent of an unclean workshop with broken and unused tools lying around. You trip over everything, you cannot find anything, your tools hurt you or slow you down.

Managers need to understand that technical clutter is central in hindering and slowing development. Not a separate account that is not affecting work.

View on HN

This is an analogy, used in communication with non-engineers. As such the analogy is valuable not for its accuracy to us, but to the people we are speaking to. If you tell someone about "clutter" in the code, to the other person that sounds like a failing, something that should be avoided, something that we should just do better at. And something landing at the feet of the engineers to deal with, because it's their fault to begin with.

Whereas the concept we are trying to get across is: we have accepted some things that are less than ideal (code quality) in order to gain in another area (probably time to release). A tradeoff, and more importantly a tradeoff driven by concerns outside of engineering's domain.

I might agree that the term is overplayed and watered down, but any replacement has to include the role that the business side plays in the problem.

As analogy one could go for updating to bigger and better.

Like, when we were a small company we were delivering our stuff with metaphoric bicycles, because they are cheap and good for the environment.

Then we updated to motorbikes for faster delivery.

Now our customer base has grown, and we have a lot more stuff, so we are updating everything to trucks, and need time to dispose the bikes that we do not need anymore.

Then finally, we have become an international company and need to update to cargo planes.

And when they try to blame the engineers that it is their fault and they should have been using the biggest thing from the beginning, you can say: You do not buy a 747 to deliver stuff to you neighbor on the same street.

I've seen this sentiment a few times. I'm not totally against it, and a better analogy is always worth considering.

I'm sure it's not the final iteration of analogies we use to garner more budget or help clients understand that always pushing for the cheapest solution isn't the best idea. But I think it does a reasonable job. It abstracts away the finger pointing of "you coded it badly" vs "you never give us enough time to do it well."

Taking terms to a client like clutter, bad code, spaghetti code, and other more direct terms I've seen lead straight to uncomfortable questions about capability, experience, and so on.

I think if it's explained with the idea of compound interest it conveys the growing impact over time if it's left undealt-with, and it's an analogy most people are familiar with.

It's definitely easier to push back on taking a shortcut using the debt analogy than by saying it will force us to make their product badly and please pay us for the privilege.

I totally get what you're saying, personally I will always speak my mind and put my foot down where appropriate, I avoid working with people that constantly just push for more with less. Even then though people still often want things done and don't understand what they're asking for.

It's definitely better than the house-building analogy that causes eyes to roll so far back they roll out of the boardroom and down the hallway. Trying to explain how code complexity really works puts everyone to sleep and no one understands it anyway.

I'd be really interested in a compendium of boardroom analogies come to think of it. Could be a fun read.

I think the important analog for the debt part is that it accumulates over time. At some point you are only paying off your technical debt, instead of building new features. At that point your project is bankrupt.

Ultimately, your suggestion is problematic - it moves culpability for technical debt/clutter from management/customers to the developers.

With "technical debt" you could argue that business demands coming down to "I want it NOW" will lead to slower or more work later, and give management agency in determining if that is in line with the value they expect to gain.

With "technical clutter", the problem is moved to the devs: They could just have, you know, "worked cleaner" to begin with (nevermind we never gave them the time to do so). It's their own mess that originated by their decision, not the mess caused by PMs or customer expectations. And if the mess caused by mess-inducing management tactics becomes too big, management would just fire "bad" devs and hire some newbies.

So ... I do get where you're coming from. With normal people, the difference in meaning would lead to better understanding. But management has a large amount of non-normal folks.

"Technical debt" as it is used today is already not owned/understood/wanted by management, but only by technical teams, so what difference does it make here?

I think "technical debt" works as an analogy because businesses traditionally see written code as an asset. And "technical debt" makes it clear that the value of that asset is being reduced, and communicates the fact that if the debt becomes large enough then that asset can actually become a liability.

> You trip over everything, you cannot find anything, your tools hurt you or slow you down.

This is the interest you pay. 'Debt' captures the problem of it being an ongoing cost.

I think the useful implication of debt over clutter is that by creating it, you’re borrowing time from your future self.

Interesting take -- but if I create clutter, I'm also borrowing time from a future self. (Well, a future person -- whoever pays off the debt or tidies up.)

the impact of clutter doesn't necessarily compound over time the same way debt does. It can, perhaps, but I don't think it's as consistent an analogy. A lot depends on how often the 'thing' is used (thing being the code/system/space/etc). I have some systems that are, indeed, cluttered, and it's difficult to return to them when, but I rarely do (1-2x per year for updating a couple files). It's cluttered, and would take time to find what I need, but it's not really under 'active' development where the cluttered code may continually get built on (adding to the clutter, at the very least).

You'd regularly clean a building you live or work in. You probably won't do the same to a building you have to enter once a year for 10 minutes just to go in to change a light bulb. Even if it's dirty or cluttered, the ROI probably isn't there.

I may be misremembering but I think it was Jessica Kerr who suggested calling it “escalating or compounding risk.” I quite like that because it makes the consequences clearer.

> We should stop calling it "technical debt". That word suggests a clean account that can be paid off from time to time.

Not all debt comes with terms that allow it to be paid off "from time to time". Most personal debt does, but the debt that corporations deal with often has very strict, inflexible payment terms.

I find a big part of the problem can be "product debt." It consists of legacy product whose owners may not even be around any more, and no current product manager is willing to risk their neck to let engineering retire it. This ends up blocking a lot of proper "technical debt" cleanup.

http://laughingmeme.org/2016/01/10/towards-an-understanding-...

I’m a big fan of “Contagion” or “Technical Contagion” to make it clear that the longer it’s there the more its effects will spread to everything it touches and the harder it will be to get rid of.

Reply on news.ycombinator.com