Tech-debt management tool

[ahumbledeveloper]

In the pool of technical productivity/management/planning tools, I feel there is another specific tool/component that's missing...

A problem I've experienced a lot comes about when we defer writing cleaner, more maintainable code to the future. Situations where we have realised a better design or further work to make the code more maintainable, which we'd like to do next time we visit the area.

This is a big issue with legacy systems when e.g. a request to add in a seemingly simple feature turns in to a nightmare as you realised the code isn't fit for unit tests etc. We've committed to only spending a small amount of time on putting in the new feature but need to remember when we revisit the code to plan in more time to make testable.

I have some vague ideas as to how we could accomplish this:

• Integrate with larger productivity tools (e.g. JIRA) used for planning and have a way of linking issues to areas of code that need changing. Linking feature issues and tech-debt issues would allow the tool to prompt in advance as a feature issue is coming up to be taken on. I see the potential of this to be pretty large as you could further develop it to learn what features require what parts of code to change (based on key words and historic commits).
• A nice way to tag code (again this may need to be a plugin for something like sublime). You'd want to avoid littering code with ToDo comments and these tags would also need to be highly visible during planning to get the required foresight.

[MatthewJWalls]

+1 to this idea because dealing with it is the bane of my life.

Need to come up with reasons why a specialised system is better than raising bugs in a tracker labelled as "refactoring". If we can't make a convincing elevator pitch for that, it'll be a tough sell.

[MatthewJWalls]

I think there are two aspects to this problem which is:

• The goal of identifying and tracking technical debt in a codebase.
• The goal of managing carrying out refactoring work as a process.

The former you kind of want as close to the code as possible, if not in it, since then it can be source controlled and carried around and engineers will just see it. The latter sounds like more specialised issue tracker.

[ninjabear]

The problem with this is purely a human one, as in if it was just you you'd fix it there and then right? It strikes me that that's the idea of refactoring and you'd just be solving a problem that your boss is making you not fix it, or the system requires it

[ninjabear]

And that makes me rage about work too much as they're repeat offenders for "refactoring for ron"

[MatthewJWalls]

I assume this is more about architectural problems which you can't just fix off-hand. Or you might notice a problem while reading code, but aren't working in that area and want to fix later.

[ahumbledeveloper]

Yeah, agreed Matt - those are the two aspects we'd need to crack. I feel there are simple ways to accomplish a very basic solution that relies more on process and convention, and iterate from there.

I think this is still important for independent developers (and not only a problem due to managers or pressures). If we were left to our own devices we could gold plate to our hearts content, but I think independent developers have to put the pressure on themselves, instead. The advantage independent developers (or small teams) have though, is they can likely recall what sort of tech debt will be beneficial before implementing a new feature or bug fix.

This would definitely require more thought...