
Ask HN: How does your team manage tech debt? - sunmist
My team recently built out a new React app from scratch and we were planning on building it as perfectly as possible. However, due to deadlines and requirement changes reality struck and we were forced to make shortcuts. There is a bunch of tech debt and a lot more feature requests.<p>What are some good strategies to manage the existing tech debt while also having time to build out the new features. What does your team do?
======
bkovacev
We use multiple things.

* We do code reviews and inline/trello todos. If we're on a tight schedule, this helps us remember why and what needs to be reworked.

* When adding new features we use regular development cycle (spec, design, review, develop, test, finish), but we also add one more process before finishing that is focused on improving todos from previous cycle. The reasoning is that after todos have been sitting there for a while, you might look at them a bit differently and while something wasn't as obvious back then it might become now. Refactoring matters a lot to us. We don't overdo it however and dedicate 1-3 days to it from the cycle.

* If any major/breaking version of react/django/drf comes out, we pause and update the tech stack. Run tests and fix any issues.

* If any major bug that hinders the users experience occurs we allocate resources in parallel with the current dev cycle.

* Update the documentation early and often.

* Write tests. Tests force you to kill the debt before it happens. We have much better unit test coverage than integration test coverage for our front-end.

------
sidlls
A couple of strategies have worked for teams I lead.

One is to simply let the system fester until it falls over due to the debt and
causes a customer to complain loudly, or if you have a competent Product
owner/manager with your team she recognizes the need to pay it off before it
becomes an issue. This is useful in an environment where product or sales want
to deliver more quickly than good engineering allows. Note: _document what is
tech debt and why it exists as you build features._ Make it clear _while the
features are built_ that the speed of development is not sustainable and use
your documentation as support. Keep metrics (e.g. profile your code) and
document how to make them better. You should know what is and isn't tech debt
in this scenario. Document it so that you cover your butts _and_ demonstrate
the willingness to help the team achieve it's product or sales goals while you
demonstrate the technical proficiency that gives non-technical folks
confidence in your team.

Another is to simply keep a well documented log of items that are recognized
as technical debt after the fact. Along with this, document how paying the
debt off benefits the business.

In both cases perhaps the most important thing is this: build relationships
with product, engineering leadership and sales to have the social capital to
be heard and allow your technical competence to carry sufficient weight for
getting time to work on debt.

------
matt_the_bass
We try hard not to create debt on purpose. But that is never easy.

We have a low volume/high ticket price product so for every feature/task/goal
we discuss as a team “will this create more customers or just make current
customers happy”. This helps us control debt because we stay focused. Often
(but not always) debt is inversely proportional to focus (at least for us).

When we do incur debt, we try to document inline: why and what. And add a todo
how to fix. We also discuss each debt as a team so everyone understands.

Usually we let it sit for one or two dev cycles. Sometimes we find we didn’t
need it in the first place and rip it out. Other times, we’d d we did need it
so we try to clean up sooner rather than later. This is pretty common for
major new features. Ship and MVP quick, then clean it up. Because we have a
long dales cycle, we often have time between demoing a new feature (mvp) and
shipping a lower sent version.

This is our more recent strategy. Obviously we have debt from long ago. We try
to clean as we go with the general trend of reducing debt (even if we have
short blips of increasing).

I realize this approach won't work for everyone and every project but it does
for us.

------
1ba9115454
\- React app from scratch

To manage technical debt you need to pick tools at the start that enable
easier and safer refactorings at a later date. JS is not a good fit for this.

The problem you have is the time spent maintaing a JS project can eat up the
time you could have used to refactor it.

