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.<p>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.<p><a href="https://neilonsoftware.com/difficult-people-on-software-projects/developers/the-hostage-taker/" rel="nofollow">https://neilonsoftware.com/difficult-people-on-software-proj...</a><p>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.<p>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".<p>Of course those softwares are out there, but I can imagine young engineers are not always aware of what is out there.
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.
Seems to be an LLM summary of the source (2023): <a href="https://ieeexplore.ieee.org/document/10109339" rel="nofollow">https://ieeexplore.ieee.org/document/10109339</a>
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.
In the original paper, it is said that of the 117 metrics they used to identify technical debt (3 of the 10 categories, TBE):<p>> 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%).
Google may not be the best example. They seem to be poor at measuring and have high tech debt.<p>As is evident by:<p><pre><code> - 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
</code></pre>
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].<p>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.<p>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. <i>DOGFOOD YOUR PROGRAMS</i>. 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).<p><pre><code> > Signs of unmanaged Technical Debt
</code></pre>
these are 100% on point. I think the writer and I are on fairly similar pages.<p>[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.<p>[1] The worst type of broken things are ones you don't realize are broken.<p>[2] <a href="https://www.reddit.com/r/memes/comments/7rdp3k/quick_maths/" rel="nofollow">https://www.reddit.com/r/memes/comments/7rdp3k/quick_maths/</a>
Managers ask their engineers to improve the tech debt scores. TODO comments and things marked "deprecated" impact it negatively. Guess how engineers fix that.<p>Also, nobody cares about the internal surveys anymore.
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.
In case it isn't obvious to everyone: the actual article title is "<i>How</i> Google measures and manages tech debt".<p>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.)