I experienced awful tech debt combined with an hostage taker, meaning a guy who seemingly refrains from giving knowledge about the software or being able to make the project progress, which gives him eternal employment, while hardly helping his colleagues to get out of the situation.
I wonder at what point a refactoring becomes just a waste of time and money compared to a slow rewrite. It becomes difficult to have an adult discussion about the subject, but obviously it's about money and how clients don't have a choice.
There are softwares out there that are just waiting to be put out of their misery, until another savior company finally builds a viable replacement.
At some point it becomes a true crisis of faith, "is it realistically possible to get work done at this job, and should I be okay earning money by mopping the rain".
Of course those softwares are out there, but I can imagine young engineers are not always aware of what is out there.
cadamsdotcom · 5m ago
That hostage taker needs a new plan because now LLMs can generate code docs.
darkwater · 43m ago
This article sounds like somebody fed an LLM with the original report and asked for a summary for a tech article, and then added some human touches here and there.
evandena · 25m ago
ChatGPT loves using emojis in eactly this manner
stronglikedan · 4m ago
Using emojis as bullet points has been a thing in tech articles since emojis were a thing, so if anything, ChatGPT loves using them like that because people love using them like that. (I.e., it's not a good litmus test for AI.)
awkward · 1h ago
This is solid and necessary. The alternative to an objective measurement of debt is debt expressed in contempt. Even putting things in deep backlog to get commented on every couple months is better than letting these decisions on priority go completely unacknowledged.
frollogaston · 4m ago
I'm fine with the contempt approach. New business priority comes in, and the software can't support it because of tech debt, so someone fixes it.
Otherwise, even if people tackle the tech debt in good faith, they spend endless time polishing things that don't really matter. Something big like a database or API is deeply flawed, and they focus on improving the unit tests, which further entrenches the broken stuff because any replacement now has to meet the same standards.
frollogaston · 18m ago
Managers ask their engineers to improve the tech debt scores. TODO comments and things marked "deprecated" impact it negatively. Guess how engineers fix that.
Also, nobody cares about the internal surveys anymore.
Mithriil · 1h ago
In the original paper, it is said that of the 117 metrics they used to identify technical debt (3 of the 10 categories, TBE):
> The results were disappointing, to say the least. No single metric predicted reports of technical debt from engineers; our linear regression models predicted less than 1% of the variance in survey responses. The random forest models fared better, but they had high precision (>80%) and low recall (10%–25%).
godelski · 1h ago
Google may not be the best example. They seem to be poor at measuring and have high tech debt.
As is evident by:
- the decrease in quality of search
- Poor response to SEO techniques (seems they embraced it...)
- Decrease in spam filtering
- I frequently get spam now. A fair number have crazy original messages that are pages long but display a single image in the main interface
- Constant drops on projects that someone else makes popular a few years later
- A million more things
The best way to reduce tech debt is to slow down and take care. It requires good culture. It requires writing (at least some) documentation. It requires constant review and rewrites. In fact, Google has the advantage in being so big they can just hire teams to rewrite stuff from scratch[0].
I think anyone junior should take a different strategy. Stop trying to be fast. It doesn't matter how fast you are if it is broken[1,2]. Write things 3 times. First is fast and broken. If you're using python or similar, do this in the interpreter. Second, move it over to the main code. Start building some documentation and make sure to explain what things do. Doesn't need to be long. Functions should be simple and not do much, so you also should only need a few lines (a few minutes is usually enough) 3) Rewrite accounting for the things you realized were issues while writing those docs. This strategy will be slow at first, but it gets fast and most importantly, you are saving yourself time in the future. These savings are invisible but invaluable.
I've been trying to say that engineers should be grumpy. Our job is to find problems and fix them. Get complaining! What frustrates you? You have the power to fix those things. It's the manager who is supposed to be thinking about the monetary parts but you should be thinking of the technical and user parts. DOGFOOD YOUR PROGRAMS. Be proud of what you're making. If you aren't using it, why are you making it? (rhetorical) If something is actually an issue, make a fuss. Don't let your manager dismiss it. You have different expertise levels and part of the job is to bridge the gap with communication (it should be bidirectional, but you can't control them, you can control you).
> Signs of unmanaged Technical Debt
these are 100% on point. I think the writer and I are on fairly similar pages.
[0] The advantage of writing from scratch is you get to leverage the knowledge you learned along the way. This can't happen if you don't document though. A big part of tech debt occurring in the the first place is that we don't know all the requirements at the time we wrote. The projects evolve over time and often in ways we can't predict. Sometimes the best thing to do is start over because you can only patch so many times before shit falls apart.
[1] The worst type of broken things are ones you don't realize are broken.
All of those things are real problems with Google, and its decisions, but they don't seem to be signs of technical debt. I suppose they _could_ be, but they could all have plenty of other causes, many of which seem more plausible to me.
1. Decreasing quality of search and poor SEO technique responses may be caused by technical debt, but they also might be the results of strategic product decisions to make more money. That isn't technical debt, that's enshittification for money.
2. Similarly. If Google chooses to do worse spam filtering in order to get more advertising in front of its customers (for example), that's a bad product decision, not technical debt.
3. Constant drops on projects are simply resource allocation decisions, unless of course, they are dropped because they are too expensive to maintain. But there are a myriad of other reasons a product might be dropped.
4. A million more things.
There are numerous valid reasons to dislike Google these days (and I say that as an employee!), but tracing them all back to technical debt is finding the wrong reason for real problems.
Similarly with worse spam filtering.
greiskul · 1m ago
Honestly I don't know how much the decrease in search quality is not just a reflection of the decrease in web quality in general. The web used to be full of indepent writers in publicly accessible websites like blogs and forums. So much of that has moved into walled gardens that are just not crawlable.
ryoshu · 1h ago
The first three sound like political decisions. Measurement and understanding doesn't mean action if the company's goals aren't aligned.
godelski · 33m ago
I wouldn't call that political, though the politics sure can cause it.
Measurements are never perfect and we need to stress this a lot. A measurement is meaningless without good interpretation. People want to ignore the latter and often politics is the means of resolution. But what matters more? Who sounds right or who is right. It's usually easy to identify experts because they can't ignore nuance. But they're long winded, boring, and present more complicated solutions. That's misinterpreted as dismissal (and sometimes they are too quick to dismiss).
It's always about alignment. The whole tech debt thing is alignment. A big issue is many of our big companies have sacrificed future earnings but short term ones. These are good decisions if you only care about shareholders and if by shareholders you mean short term investors who have no interest in the long term stability of the organization. But if you want a company to last and you want long term profits to be high then these usually aren't the best decisions. The bigger question is why everyone has become so myopic. https://news.ycombinator.com/item?id=43873275
2OEH8eoCRo0 · 3h ago
Google is obscenely rich and can spend cycles doing this.
laweijfmvo · 4m ago
a lot of companies can [afford to]. most don't.
hiddencost · 1h ago
Lol false. Google killed their internal culture which prioritized supporting and trusting engineers to do the right thing. They replaced them with grifters who would lie to management claiming they could measure technical debt.
frollogaston · 38s ago
So who told them to make 20 terrible chat apps, the engineers?
jldugger · 21m ago
> Google killed their internal culture which prioritized supporting and trusting engineers to do the right thing. They replaced them with grifters
Please, tell us more.
FrustratedMonky · 57m ago
My experience with engineers, is they love to complain about 'others technical debt', but love going into debt themselves.
ralusek · 1h ago
Google manages tech debt by throwing away products after a couple of years
euroderf · 46m ago
Culling the herd ?
gjm11 · 32m ago
In case it isn't obvious to everyone: the actual article title is "How Google measures and manages tech debt".
I am not sure I have seen a single case in which the HN delete-initial-"how" transformation improves an article title. (I concede that it's possible that I just haven't noticed the ones where it's an improvement.)
I wonder at what point a refactoring becomes just a waste of time and money compared to a slow rewrite. It becomes difficult to have an adult discussion about the subject, but obviously it's about money and how clients don't have a choice.
https://neilonsoftware.com/difficult-people-on-software-proj...
There are softwares out there that are just waiting to be put out of their misery, until another savior company finally builds a viable replacement.
At some point it becomes a true crisis of faith, "is it realistically possible to get work done at this job, and should I be okay earning money by mopping the rain".
Of course those softwares are out there, but I can imagine young engineers are not always aware of what is out there.
Otherwise, even if people tackle the tech debt in good faith, they spend endless time polishing things that don't really matter. Something big like a database or API is deeply flawed, and they focus on improving the unit tests, which further entrenches the broken stuff because any replacement now has to meet the same standards.
Also, nobody cares about the internal surveys anymore.
> The results were disappointing, to say the least. No single metric predicted reports of technical debt from engineers; our linear regression models predicted less than 1% of the variance in survey responses. The random forest models fared better, but they had high precision (>80%) and low recall (10%–25%).
As is evident by:
The best way to reduce tech debt is to slow down and take care. It requires good culture. It requires writing (at least some) documentation. It requires constant review and rewrites. In fact, Google has the advantage in being so big they can just hire teams to rewrite stuff from scratch[0].I think anyone junior should take a different strategy. Stop trying to be fast. It doesn't matter how fast you are if it is broken[1,2]. Write things 3 times. First is fast and broken. If you're using python or similar, do this in the interpreter. Second, move it over to the main code. Start building some documentation and make sure to explain what things do. Doesn't need to be long. Functions should be simple and not do much, so you also should only need a few lines (a few minutes is usually enough) 3) Rewrite accounting for the things you realized were issues while writing those docs. This strategy will be slow at first, but it gets fast and most importantly, you are saving yourself time in the future. These savings are invisible but invaluable.
I've been trying to say that engineers should be grumpy. Our job is to find problems and fix them. Get complaining! What frustrates you? You have the power to fix those things. It's the manager who is supposed to be thinking about the monetary parts but you should be thinking of the technical and user parts. DOGFOOD YOUR PROGRAMS. Be proud of what you're making. If you aren't using it, why are you making it? (rhetorical) If something is actually an issue, make a fuss. Don't let your manager dismiss it. You have different expertise levels and part of the job is to bridge the gap with communication (it should be bidirectional, but you can't control them, you can control you).
these are 100% on point. I think the writer and I are on fairly similar pages.[0] The advantage of writing from scratch is you get to leverage the knowledge you learned along the way. This can't happen if you don't document though. A big part of tech debt occurring in the the first place is that we don't know all the requirements at the time we wrote. The projects evolve over time and often in ways we can't predict. Sometimes the best thing to do is start over because you can only patch so many times before shit falls apart.
[1] The worst type of broken things are ones you don't realize are broken.
[2] https://www.reddit.com/r/memes/comments/7rdp3k/quick_maths/
1. Decreasing quality of search and poor SEO technique responses may be caused by technical debt, but they also might be the results of strategic product decisions to make more money. That isn't technical debt, that's enshittification for money.
2. Similarly. If Google chooses to do worse spam filtering in order to get more advertising in front of its customers (for example), that's a bad product decision, not technical debt.
3. Constant drops on projects are simply resource allocation decisions, unless of course, they are dropped because they are too expensive to maintain. But there are a myriad of other reasons a product might be dropped.
4. A million more things.
There are numerous valid reasons to dislike Google these days (and I say that as an employee!), but tracing them all back to technical debt is finding the wrong reason for real problems. Similarly with worse spam filtering.
Measurements are never perfect and we need to stress this a lot. A measurement is meaningless without good interpretation. People want to ignore the latter and often politics is the means of resolution. But what matters more? Who sounds right or who is right. It's usually easy to identify experts because they can't ignore nuance. But they're long winded, boring, and present more complicated solutions. That's misinterpreted as dismissal (and sometimes they are too quick to dismiss).
It's always about alignment. The whole tech debt thing is alignment. A big issue is many of our big companies have sacrificed future earnings but short term ones. These are good decisions if you only care about shareholders and if by shareholders you mean short term investors who have no interest in the long term stability of the organization. But if you want a company to last and you want long term profits to be high then these usually aren't the best decisions. The bigger question is why everyone has become so myopic. https://news.ycombinator.com/item?id=43873275
Please, tell us more.
I am not sure I have seen a single case in which the HN delete-initial-"how" transformation improves an article title. (I concede that it's possible that I just haven't noticed the ones where it's an improvement.)