How Google measures and manages tech debt
newsletter.techworld-with-milan.com
newsletter.techworld-with-milan.com
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.
done.
extra, fire them before they take hostage the new system.
Original content: 3,060 words 19,499 characters
I user Reader mode, and while I included the short embedded ad in the middle, I paid care to not select the other embedded ad at the end.
Did not check if or how much the emojis bloat the word count, or how many other embedded ads there might be that I couldn't find.
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.
Goldbricking and polishing turds are definitely pitfalls, but the benefit of a low debt codebase is insanely fast turnaround. If you want to optimize for that, you need to do some fixes in anticipation of need, and sometimes those will be wrong.
Rewrites should bring a lot of skepticism, and are often worse than turd polishing. If it's gotta happen people should be able to take that on evidence rather than respond because they've developed feelings for the turd.
The tech debt is still costly, but most of it isn't caused by lack of maintenance, more that something was designed fundamentally poorly from the start.
The question I'd ask is, shouldn't we have tools that make it super easy to change things, so we can adapt to different outcomes without it becoming a huge slog?
> 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%).
Please, tell us more.
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
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
[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/
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
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.
But the problem I'm talking about is SEO (search engine optimization). It is the reason for things like a page telling you about a recipe also has a long story about their grandma and how this recipe brings back all those memories in vivid details they share with you. Is it dwell time that matters? Is it more words? More "context"? I don't know, but I know that those sites get better traction. It's no surprise that writing a good search algorithm is extremely difficult. Especially as what's a measure of something useful in one context may also be a measure of shittiness in another. But ultimately would that not fall under tech debt? Making the wrong decisions, making poor approximations, etc. It's also a constant battle as websites want to get their results to the top. I'm not trying to say it is an easy task, but I think Google is on the losing side of the battle and decisions like LLM generated answers don't seem to be addressing the underlying issues and more seem like short term solutions that help the stock go up "because AI". Hell, this is CS, how often do we praise someone for being a pioneer in VR, and in blockchain, and in AI? Why is having those three things on your CV seen as a green flag instead of a red one?
> but they don't seem to be signs of technical debt
> they also might be the results of strategic product decisions to make more money. That isn't technical debt, that's enshittification for money.
> that's a bad product decision, not technical debt.
| technical debt refers to the implied cost of additional work in the future resulting from choosing an expedient solution over a more robust one.
- Wiki[0]
Also, nobody cares about the internal surveys anymore.
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.)