Live data from Hacker News

How Google measures and manages tech debt

newsletter.techworld-with-milan.com

31–36 of 36 posts

Re: How Google measures and manages tech debt

#31

Earlier quoted context omitted.

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.…

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.

A lot of the walled gardens are recent. Scarping massively increased due to the LLM era. There's always been mitigations, but the scale of the issue was different.

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?

Re: How Google measures and manages tech debt

#32

Seems to be an LLM summary of the source (2023): https://ieeexplore.ieee.org/document/10109339

LLM "summary" / rephrasing: 3,272 words 20,939 characters.

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.

Re: How Google measures and manages tech debt

#34
post #4

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.

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 beca…

Contempt is corrosive, and if you're fixing debt in response to business needs that's putting the turnaround on real business needs at risk.

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.

Re: How Google measures and manages tech debt

#35
The flip side of technical debt is, what tools do you have to actually solve technical debt? Some technical debt comes from conscious decisions to choose an expedient solution over a long term one, but a lot of it just comes from not knowing what the future is going to bring, and not wanting to over-engineer for every possible outcome.

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?

Re: How Google measures and manages tech debt

#36
post #34

Earlier quoted context omitted.

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 beca…

Contempt is corrosive, and if you're fixing debt in response to business needs that's putting the turnaround on real business needs at risk. 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 sk…

I get that it's risky and expensive, but I haven't seen it work better than this. The hack workaround sometimes ends up being better than the existing system, cause a rushed timeline forces everyone to be frank about what's actually needed and what they can ignore. They're also forced to pick something simple, not design an overly grand solution with tons of meetings.

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.

Post reply on HN