4 ms·
Ask HN: How are you fighting tech debt in your project?
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.
- fredrb 8y agoI 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 8y agoThanks for the repies we are doing the same almost :)
- chupa-chups 8y agoAt 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 8y agoSo, 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 8y agoNo, 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 :-)