zlacker

[parent] [thread] 31 comments
1. xyzele+(OP)[view] [source] 2023-10-12 20:07:05
Various debt has different "interest rates" and the skill is to pay off the high interest ones as the expense of 0-rate ones.

I have a closet in the basement where when I did the vinyl plank floor, I ran out so the planks don't quite go to the back of the closet all the way. Problem? Yes? A bit ugly? Yes. But in reality the problem is 100% of the time covered by boxes and anyway I can live a happy life in this house for decades and not be affected. That's 0% tech debt.

On the other hand if my gutters are clogged, there's interest on that because the longer I wait the costlier it will be to deal with since clogged gutters can lead to basement leaks or gutters themselves detaching. Or, if my stoop is broken, that's not just an eye sore but I keep tripping on it, the faster I fix it the sooner I stop tripping. That's a high-interest debt that should be fixed asap.

In engineering, a high-rate debt could be some architectural thing that slows down the development of every single feature. You want to quickly pause features to pay this down so everything can move faster. On the other hand, some file that you never touch having some shitty code or lots of TODOs may be a very low interest debt since in practice you never touch it or are otherwise not bothered by it other than knowing that it's ugly - like my closet floor.

Engineers make two mistakes around this - fixing zero-interest debt when there's more important things to do on one hand. On the other hand, when they say "oh, product management/leadership didn't sponsor our tech debt fixing" - it's often because we fail to articulate the real cost of that problem - explaining that it's high rate and how it's costing you.

replies(6): >>Bognar+k6 >>hifycy+17 >>autoka+gc >>PH95Vu+UE >>briHas+fP >>adrian+ZZ
2. Bognar+k6[view] [source] 2023-10-12 20:40:34
>>xyzele+(OP)
I love this analogy, interest rates on tech debt. It's such a natural extension of the phrase tech debt and succinctly gets a point across. I'm gonna have to steal that and start using it at work.
replies(1): >>munifi+L8
3. hifycy+17[view] [source] 2023-10-12 20:44:15
>>xyzele+(OP)
That's a nice story but at my company management actively discourage all forms of code hygiene. The only thing they care about is code shipped. It comes down to a perverse set of incentives from the csuite but it 100% has zero to do with developer articulation.

Nobody gets in shit for telling their developers to code faster.

Lots of risk telling them to fix the underlying issues so they can ship faster in the future.

replies(2): >>m463+V9 >>xyzele+yG
◧◩
4. munifi+L8[view] [source] [discussion] 2023-10-12 20:54:05
>>Bognar+k6
> It's such a natural extension of the phrase tech debt and succinctly gets a point across.

The metaphor of interest was the whole reason that Ward Cunningham initially coined the term "tech debt":

"Technical Debt is a metaphor, coined by Ward Cunningham, that frames how to think about dealing with this cruft, thinking of it like a financial debt. The extra effort that it takes to add new features is the interest paid on the debt."

https://www.martinfowler.com/bliki/TechnicalDebt.html

◧◩
5. m463+V9[view] [source] [discussion] 2023-10-12 21:03:06
>>hifycy+17
until turnover is high.

Maybe it is like those restaurants with dirty bathrooms. Most customers don't care, and if you get some minimum customers management thinks a bathroom makeover won't matter.

replies(2): >>lazyas+Ug >>rewmie+pi
6. autoka+gc[view] [source] 2023-10-12 21:17:27
>>xyzele+(OP)
> oh, product management/leadership didn't sponsor our tech debt fixing" - it's often because we fail to articulate the real cost of that problem

I disagree. they simply don't care because from the top down, new shiny stuff gets attention, not keeping the old stuff going.

edit: I also wanted to add this, if I do convince them of its importance, MAKE NO MISTAKE, management will agree that work must be done but it has absolutely NO BEARING on having a positive job performance. I just convinced management of something important that I have to do that I will receive no benefit from - unless it goes wrong then I'll get reprimanded.

replies(3): >>datagr+tk >>brails+js >>johnny+001
◧◩◪
7. lazyas+Ug[view] [source] [discussion] 2023-10-12 21:43:11
>>m463+V9
Turnover at my company is through the roof and management just moves on to other companies as well. New management people are just as reluctant to believe devs saying "well, this code is a pile of shit and so no we really shouldn't be all-in on quickly releasing your favorite new feature".
◧◩◪
8. rewmie+pi[view] [source] [discussion] 2023-10-12 21:51:01
>>m463+V9
> until turnover is high.

You're making it sound like having someone quit is a blocker. Some managers see that as shedding the dead weight, and keeping in the guys who are the team players with endurance. The guy who complains about code quality suddenly leaves and all of a sudden there are no more complains about code quality, and worst case scenario you have new joiners trying to onboard and cause a good impression who don't care if code is shit because their goal is to shine.

How did you solved that problem?

replies(1): >>Michae+Nk
◧◩
9. datagr+tk[view] [source] [discussion] 2023-10-12 22:03:34
>>autoka+gc
That may be your experience, but I assure you that there are plenty of companies where it's not like that. Where I work, our product team is pretty receptive to us taking time to fix tech debt, since:

- Engineering is very transparent about explaining when tech debt is slowing down development of new features

- We recognize that buggy/unreliable software hurts customer retention

- Engineering leadership has set the expectation that a significant portion of each team's time should be spent on maintenance and reliability.

◧◩◪◨
10. Michae+Nk[view] [source] [discussion] 2023-10-12 22:06:12
>>rewmie+pi
It's self correcting as customers will move to the competitors over time.

If it's one of the few business that has an absolute monopoly over a certain sector in a country, then the country will gradually weaken over time, until eventually it won't be able to resist a foreign competitor.

Or at least that's what market theory suggests. Of course the period of 'self-correction' could take a few months to a few centuries to fully play out, and simultaneously overlaps with all other market participants.

◧◩
11. brails+js[view] [source] [discussion] 2023-10-12 22:58:42
>>autoka+gc
You're conflating what is important with what seems important, and what your job is with what you'd like your job to be, and that's a dangerous, burnout inducing, trap.

Important, in the context of a hierarchy-driven development team or company, is defined first by the best way to let money flow towards the company, and second by the people who are enabled by the hierarchy to make decisions about where to allocate resources to improve that inflow of capital. While persuading someone it's momentarily important to shift from what was going to be done to what you think should be done can be one way to acquire "career capital" (Newport) and maybe move towards it being your job to do so, it doesn't change what your current job is which is basically to consistently show up and do whatever those others decide is important, and to be ok with that; slow, mediocre, gradual progress and existence, which is perfectly fine if you have other part s of your life, which you should be spending more time on anyway. If new shiny stuff gets attention, then that's part of the dysfunction of the overall system (Meadows - Thinking in Systems)

When I was early in my stupid career as an developer, I made the idiotic mistake of trying to influence decisions regarding things that didn't matter to anyone else, like accessibility, usability, and when I failed to do so put in a lot of my own personal energy to do it right anyway. That was worthless, and I got depressed, fired, and ended up homeless for a while. Do what you're paid to do, and be realistic about what that is, until you're literally swatting people away who want to pay you to do it, then you can do it the right way. Never trust companies for any reason, and don't invest too much of yourself in them unless you can guarantee positivity will come your way if you do things beyond your standard deliverables.

replies(1): >>johnny+E71
12. PH95Vu+UE[view] [source] 2023-10-13 00:39:18
>>xyzele+(OP)
> But in reality the problem is 100% of the time covered by boxes and anyway I can live a happy life in this house for decades and not be affected. That's 0% tech debt.

what's amazing is that I'm apparently in debt while owing absolutely nothing to anyone.

When you say something like "0% tech debt" seriously, do you ever stop and wonder if maybe you're off-base?

Debt needs to be serviced, if you don't need to service it, it's not debt.

What next, that feature that hasn't been implemented yet is 0% tech debt?

replies(1): >>xyzele+0G
◧◩
13. xyzele+0G[view] [source] [discussion] 2023-10-13 00:47:50
>>PH95Vu+UE
It seems like the analogy was unhelpful to you, although it seemed to resonate with a lot of other HNers based on the comment responses and ratings.

The main point to take away is that much of what is colloquially called tech debt does not need to be dealt with on any time horizon, while some does - and being able to distinguish between the two types is key. Were you able to get that much out of this?

And then to make the analogy work for you again - my closet IS a form of tech debt and I insist that it's "0% debt". For example, if I am going to sell the house, it might be the case that having this flawed floor would cause me to get lower offers. So I might chose to deal with this issue at some point, but there's no reason to deal with it any sooner (analogous to not being in the rush to pay off a zero-interest loan)

replies(1): >>PH95Vu+FO
◧◩
14. xyzele+yG[view] [source] [discussion] 2023-10-13 00:52:32
>>hifycy+17
I am not sure you totally understood my point.

"Code hygiene" is not a goal but the means to a goal. The reason hygiene is good is that ideally should (1) enable you to ship faster and (2) have fewer bugs so you can focus on shipping the next thing instead.

So then there's two options - if your hygiene doesn't give you (1) and (2) then it's pointless. On the other hand, if you do have a velocity issue because of bad hygiene, then that sounds in line with your c-suite concern.

"hey boss, our code needs to be more hygienic" - nobody cares.

"hey boss, we are at 10% of possible velocity because of issues X,Y,Z, and we can be 10X faster if we take a month to fix those" - now they are listening.

replies(1): >>koonso+fi1
◧◩◪
15. PH95Vu+FO[view] [source] [discussion] 2023-10-13 01:56:33
>>xyzele+0G
your closet is unfinished, nothing more, nothing less.

If the porcelain top on my toilet breaks, I'm not in debt because I choose not to replace it.

now, I can run around and tell everyone my toilet is now causing me to have 0% debt because I have a right to say whatever I want, but words have meaning and me saying it doesn't make it so anymore than me claiming the earth is cheese has any effect on whether or not it is. Unless of course by cheese I really mean iron when I say cheese.

replies(3): >>xyzele+aQ >>sokka_+701 >>johnny+C11
16. briHas+fP[view] [source] 2023-10-13 02:01:49
>>xyzele+(OP)
I agree with your analogy, but for a large team, you can't ignore the 'broken window theory' [1] as it applies to code quality. If the codebase is messy and inconsistent, even in those 'hidden' files, developers are going to be less inclined to implement their new feature(s) with any consistency or quality. "I'll just hack this thing in here, since we really need to rewrite this entire module anyway; we'll clean it up then..."

[1] https://en.wikipedia.org/wiki/Broken_windows_theory

replies(1): >>johnny+u01
◧◩◪◨
17. xyzele+aQ[view] [source] [discussion] 2023-10-13 02:10:21
>>PH95Vu+FO
I am taking that you've absorbed the larger wisdom of the post and can't resist being dense on the analogy, so I'll call it a success for both of us :)
replies(1): >>PH95Vu+x72
18. adrian+ZZ[view] [source] 2023-10-13 03:42:33
>>xyzele+(OP)
The problem is that in many cases figuring out which is the 0% interest debt and which is the expensive debt often costs about as much as fixing it. So blaming the developers for "not articulating the real cost of the problem" is a bit of a cheap excuse. If the debt causes customer visible problems it has a chance of getting addressed. If the problems are only internal, the chances are much lower.
◧◩
19. johnny+001[view] [source] [discussion] 2023-10-13 03:42:34
>>autoka+gc
It's a mix of both, depends a lot on the sponsor. Some may figure it out but it wasn't explained properly. Others may do as you say even if Einstein himself said we needed this refactor otherwise WW3 would start.
◧◩◪◨
20. sokka_+701[view] [source] [discussion] 2023-10-13 03:43:38
>>PH95Vu+FO
In your stubborn response, have you considered Jesus?

No no, seriously. You need a counter party to your debt. What about a divine figure?

◧◩
21. johnny+u01[view] [source] [discussion] 2023-10-13 03:45:54
>>briHas+fP
You can also lack the authority depending on the codebase and seniority. I still freshly remember a one line fix in a large game codebase I could have fixed right then and there, but had to simply file a bug for because that part of the codebase was managed by some other studio.
◧◩◪◨
22. johnny+C11[view] [source] [discussion] 2023-10-13 03:55:03
>>PH95Vu+FO
>If the porcelain top on my toilet breaks, I'm not in debt because I choose not to replace it.

you do know what "tech debt" is, right? In your metaphor, your top may have 0% debt because only you use the bathroom and no one cares, or it has a potentially high debt in that you receive more germs from your bathroom and get more sick, costing you money to buy medicine to keep you not sick. The debt is objective but we live in a world where finding that objective measure is infeasible.

to use your cheese metaphor, it's more like boldly claiming the earth is 35% iron. it's something you can quickly google and is acceptable through decades of study, but it also wouldn't be surprising if better tooling and measurements later on specify "it's actually 33.42% iron". Important for a geologist, splitting hairs for a casual audience.

We are very much a casual audience, and splitting hairs over a metaphor isn't that productive.

replies(1): >>PH95Vu+Ln1
◧◩◪
23. johnny+E71[view] [source] [discussion] 2023-10-13 04:51:00
>>brails+js
>Do what you're paid to do, and be realistic about what that is, until you're literally swatting people away who want to pay you to do it, then you can do it the right way.

yeah, assuming you get to that point before burnout or CBF kicks in. Or maybe you never do and just retire off of corporate. I imagine that exact mentality is why so many game dev programmers burn out and chase the money they deserve in others parts of tech.

replies(1): >>brails+3z3
◧◩◪
24. koonso+fi1[view] [source] [discussion] 2023-10-13 06:38:50
>>xyzele+yG
Hey, I fully agree with your original post and this one, but I wanted to present to you a crazy example I experienced years ago.

So we offered a solution to our customers, and then we could customize this by offering our own "consultant" developers. In the end, each developer had a goal to be "80% of their time billable".

Now we sometimes had to write these things called "channels", which took about 2 weeks to write. If we would have rewritten the framework behind it (which would take about 2 weeks) we could have probably sped up writing channels to less than a week! The thing was, nobody really cared if it took 2 weeks or less than a week, since the customer paid for it. My statement of 'let the customer pay for the 2 weeks anyway' never got hold (that would have probably resulted in some accountant fraud I guess, the way they set up the contract). So anyway, nobody was willing to invest this 2 weeks refactoring that would almost instantly pay itself back.

We were writing channels all the time, and it always felt like such a waste.

Sometimes in corporations, you can end up in the most crazy situations. I've seen plenty.

◧◩◪◨⬒
25. PH95Vu+Ln1[view] [source] [discussion] 2023-10-13 07:30:41
>>johnny+C11
what makes this worse is that the original metaphor was meant to try and communicate with business leaders.

There is no business leader on this earth that is going to agree with 0 debt is debt. Or that choosing not to do a thing or pay for a thing implies debt.

And it gets even worse when you take it to its logical conclusion. Choosing not to fix something is apparently debt. So then if you take out a loan to fix it it's also debt?

What the poster meant is it doesn't always harm anything to leave something unfinished or imperfect. Which is true, but then they tried to squeeze "technical debt" into that and went off the rails.

words have meanings for a reason.

replies(1): >>johnny+wo1
◧◩◪◨⬒⬓
26. johnny+wo1[view] [source] [discussion] 2023-10-13 07:38:18
>>PH95Vu+Ln1
okay, well I'm not a linguist. I wouldn't have chosen to make a dedicated word for a self-portrait picture in an official context over something practical like a singular gender-neutral pronoun. I wouldn't have chosen to make a word's extra definition be its own antonym because people can't help but engage in hyperbole. But society shapes language and its collective usage drives what words are "official".

Inaccurate or not, it's understood by people what "tech debt" means and the point of communication is to express ideas to others. Even if it spits on the queen's english, it furfills its goals. I lack the clout and energy to try and oppose and change such ideas (and to be frank, it wouldn't make the top 50 of things I would influence if given those factors).

replies(1): >>PH95Vu+r62
◧◩◪◨⬒⬓⬔
27. PH95Vu+r62[view] [source] [discussion] 2023-10-13 13:50:32
>>johnny+wo1
no one understands tech debt to mean "0 debt", you're making my point for me.

We have 1 poster abusing it and getting called out for it.

replies(1): >>johnny+nb2
◧◩◪◨⬒
28. PH95Vu+x72[view] [source] [discussion] 2023-10-13 13:56:19
>>xyzele+aQ
and now it all makes sense.
◧◩◪◨⬒⬓⬔⧯
29. johnny+nb2[view] [source] [discussion] 2023-10-13 14:16:45
>>PH95Vu+r62
If we're talking about the abuse of language: "one person disagreeing" (in this case, the subject themself) is not the equivalent of "getting called out".
replies(1): >>PH95Vu+Kf6
◧◩◪◨
30. brails+3z3[view] [source] [discussion] 2023-10-13 22:15:08
>>johnny+E71
> assuming you get to that point before burnout

My point was that the burnout lies in mismatched expectations, as well as working excessively, and yes I'd agree that's probably why game devs do that. There are better avenues for "passion" than your career unless you can trade the skills you've built up in your career for whatever you want to do for work.

Edit: Additionally, if in retrospect I just said yes to the most viable incarnation of whatever the corporate overlords wanted, and stopped caring earlier about the hypothetical implications of poor technical decisions (which I should have accepted sooner weren't a significant part of my job), then the work would have just maybe got done and whether it worked or not wouldn't necessarily be my concern, and I'd have more fuel in the tank to just keep getting better and moving somewhere else.

◧◩◪◨⬒⬓⬔⧯▣
31. PH95Vu+Kf6[view] [source] [discussion] 2023-10-15 03:15:04
>>johnny+nb2
You can't argue with my original point so instead you're trying to find something wrong with my wording.

I get to define my intent, not you. You cannot call someone out without disagreeing with the behavior or words that you're calling out. So congratulations on stating the obvious I suppose.

replies(1): >>johnny+1k6
◧◩◪◨⬒⬓⬔⧯▣▦
32. johnny+1k6[view] [source] [discussion] 2023-10-15 04:08:57
>>PH95Vu+Kf6
We're well beyond a flame war, and the worst kind. This isn't Reddit. and to be frank I felt like we were constantly talking past each other despite my attempts to align ourselves. Once we have to resort to insults, especially over how words are used, it's clear we both missed the point.

My thoughts are laid out above. I have nothing more to add on the subject. You win, and I apologize for failing to understand your point.

[go to top]