How Google measures and manages tech debt

Google is obscenely rich and can spend cycles doing this.

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.

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.

[2] https://www.reddit.com/r/memes/comments/7rdp3k/quick_maths/

The first three sound like political decisions. Measurement and understanding doesn't mean action if the company's goals aren't aligned.

My experience with engineers, is they love to complain about 'others technical debt', but love going into debt themselves.