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?
* 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.
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.
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.
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.