Ask HN: How do you effectively manage technical debt in fast-paced environments?

Technical debt is a function of management's priorities.

If management does not see good practice as a priority or prefers not to make long term choices, then there is no managing technical debt. What happens is that the number of engineers grows faster than the management and management will leave some number of engineers relatively unattended who will take it upon themselves to be a "hero" (jargon for someone who does thankless work) while they slowly become more cynical doing the equivalent of janitorial work.

The gambit every manager is making is that with today's investments in product you can hire a team to solve infrastructure problems tomorrow. That is because all these companies get advice from companies with very successful exits, but fail to see the survivorship bias and fail to see that being in a rocket ship is different than being in a cessna. Your company's advisor from google/investor's advisor from google is giving you advice from the perspective of a company that could hire an engineer and devote them to a microscopic problem if they wanted. Advice from companies that are not practically resource bound is bad advice.

Another important thing to consider is that these upper management types might incur a lot of technical debt in order to get short term gains which pads their resume which allows them to go to other companies where they then do the same thing. This is the conflict of interest that results in technical debt. Managers can create problems they won't have to solve because they can just leave.

Short-termism is a disease that can only be fought via leadership, and the fish rots from the head.

By the third time you see an obvious problem not being addressed until it becomes a catastrophe, it's probably time to understand that your leadership doesn't get it.

My take is take the lessons of other cynical people who work near operations and only work on feature production. Don't ever be the poor sap fixing problems before they are a catastrophe because nobody can understand the catastrophe before it happens. Nobody can measure the impact of resolving a catastrophe before it happens.

* Ruthlessly prioritize by pain - a lot of technical debt is "icky" but doesn't cause much pain. Some causes a lot of very serious pain. The latter is what you need to focus on. The former you need to accept you might never get around to fixing.

* Ruthlessly break down debt improvements and drip feed them into production. As an example, once when I was trying to upgrade Django I would follow this process on every other ticket:

1) Try running the app with the latest version of django. 2) Identify a small problem with that (e.g. a page that errors). 3) Try and fix it by making the code run in old AND new environments. 4) Release the changes into prod.

After a while, the accumulated changes would lead to a small release where I figured that everything worked. That's when I flipped the switch.

In startups/fast paced env, its very difficult to manage technical debts. What I follow is 80/20 based on the priorities we need to make room for handling these debts.

Avoid having redundant work because, keep stakeholders in loop because this is something necessary to be handled from start else its very difficult to handle at the alter point.

Many of the things gets fixed by automating and following few of the best practices to improve the development processes. Code reviews, Code push approvals, unit tests, integration tests, CI/CD. These reduces the debts and helps to plan to handle other debts.

Not sure I'd call this "effective", but it seems the way management has always prioritized it has been to wait until it breaks something, or almost breaks something.

Don’t create it. Use battle-tested approaches and frameworks that scale. Do quality work, at a sustainable pace.