> I would be grateful if someone could explain why they would need to cut down on tech debt in order to keep the product in a functional holding pattern. Obviou

> I would be grateful if someone could explain why they would need to cut down on tech debt in order to keep the product in a functional holding pattern. Obviously there are going to be things that break and new exploits that need to be taken into consideration, but when I think about tech debt I imagine kludge-ridden, inelegant/inefficient code that is poorly documented. The code is one part of tech debt, and the other is infrastructure around that. Just as a random example, maybe the flow to add a blue checkmark needs to pass through a service that wasn't designed to support that load. They want to make it scale horizontally, but it was written as a stateful service and the code is a mess, so something that should have taken a week or a month now takes a year. It also may depend on a service that nothing else uses, like a weird bastardization of an old MySQL. The problem with that tech debt is the inability to move quickly (even in response to outages), and the almost inevitable downtime related to trying to fix a poorly designed, poorly written, and/or poorly documented service. It also kind of prevents you from cutting the staffing levels too far, because some portion of those people are tasked with "preventing the tech debt from taking the service offline". I have no insight on how the tech debt affects Twitter in particular, but tech debt can be a very real thing.