
Ask HN: How are you fighting tech debt in your project? - rcshubhadeep
As a senior software engineer I had seen tech debt eating up months of work from very efficient engineers. And also delaying the deadline. I was wondering how are people trying to fight it? What tools exists in both developer tooling space and as well project management space.
======
chupa-chups
At our project we're trying to keep technical debt on the feature side.

That is: we're doing stories as good as possible technically including
required refactoring. We're keeping this manageable by reducing the feature
set or intentionally not implementing certain special cases (which reflect the
technical debt), of course only in discussion with the project owner.

By doing this we keep the complexity within bounds. When we are catching up on
this kind of debt it means we have to implement those omitted special cases,
which has the benefit of being completely transparent to the product owner as
well as to the developers. This may then involve to refactor entire
subsystems, but until now this was never a problem (since the business value
was always measurable).

Coding-level technical debt we're keeping track of using Sonarqube, and by
keeping all metrics on zero (either by fixing or by intentionally supressing).

This works quite well for us. We're benefitting from being a greenfield
project (a SaaS solution based on Spring Boot).

~~~
rcshubhadeep
So, basically, better spec, not changing spec once defined and tracking, and
static code analysis are the bottomline of what you are implementing.

Am I right?

Do you find that having some kind of intelligent agent based analysis on PR
and spec is going to help you?

~~~
chupa-chups
No, i don't think so at this time.

Previously i worked on a on-premise HR solution which had lots of problems
with technical debt. I think even in this case it wouldn't have helped to have
some kind of tool, since the problem was not really to know what to do but
"how" to do it.

We approached the problem by extracting domain-isolated "microservices" (i.e.
separate modules). This worked quite well, but had the usual drawback of being
"only" technical, not helping the users in any way. Bad from the POV of a
manager :-)

------
fredrb
I have been facing this a lot in my current project, and keeping long list of
GitHub issues for "tracking" of technical debts hasn't really helped. As these
never find its way to our Sprint Backlog. A couple things we started trying to
do:

(i) Try to estimate more realistically (usually higher). Consider making the
feature stable when estimating, drop the "done" and "done done" concepts. A
feature is done when it's stable, reviewed and tests green.

(ii) Don't accept pull requests that lower the test coverage of our
application (at least in modules that we already have coverage).

(iii) Pull a few technical debt items to the Sprint Backlog

We figured that it was easier to avoid creating more technical debt in rather
than trying to retroactively fix all. I've had long discussion with people
saying that we should stop for one full week and do a mass cleanup and
redesign. Not sure if I fully agree.

~~~
rcshubhadeep
Thanks for the repies we are doing the same almost :)

