(realizing I'm being a bit of a downer on this...)
Adding to the total "estimated time" for a project in Jira at some places is a "bad" thing. It makes the burn down chart go the wrong direction.
This also presupposes that a developer cares about the long term maintainability of the code. When tenures are measured in "two years? You've been there for a long time" the work that needs to be done two years and a day out isn't something that is a concern.
There is a lot of "development team did it, it's done, throw it over the wall and let the maintenance team deal with it." The maintenance team, however, is under resourced and since there aren't any good tests for the functionality, refactoring anything that isn't verifiable is much more work than fixing a bug where you can say "yep, that's done."
Management in many places isn't concerned about code quality and see it more as "developers are gold plating that project." Spending 4h to reduce the time it takes to do a hypothetical support ticket that may never occur from 3h to 1h of maintenance time (that's a different team) isn't a good investment of time.
And while there are enlightened managers out there, they are still up against the metrics of "how much did your team accomplish that the business wanted?"
Right the management would be in charge of course. They would decide whether a given TDEBT-issue should be worked on as a "secondary project" perhaps or not. I think they would still appreciate having the knowledge of the technical debt their company is taking on. You don't need to do anything about (technical or other kind of) debt until you have the money and will to get rid of it. But it's still valuable to know about it I think they would agree.
There's so many kinds of discussions going on in developer communications. Establishing a channel for technical debt within a project would seem to be not the worst waste of time.
I do agree... but I'm a FTE in that's been in my current position for 7 years. I'm not worrying about which way the burn down charts go (and sigh when the estimation is removed - well, at least it's in the history).
The issues that I've had is that as long as there is someone else that is doing the maintenance or support, or the tenure of the developer is closer to the job hopping average - technical debt is ignored at nearly every level.
> technical debt is ignored at nearly every level.
I agree. Technical debt is bad/evil and many (short-sighted) managers try to see no evil hear no evil speak no evil.
They don't want to tell their bosses the software is a maintenance nightmare which will cost the company dearly in the future.
I think we need a new better notion of "code ownership". People who write the code should in some sense "own" it. Only that way they will have a true incentive to make code maintainable and to minimize technical debt. The manager should of course own their shared of the code-ownership. They helped decide what should be in it and what not.
Adding to the total "estimated time" for a project in Jira at some places is a "bad" thing. It makes the burn down chart go the wrong direction.
This also presupposes that a developer cares about the long term maintainability of the code. When tenures are measured in "two years? You've been there for a long time" the work that needs to be done two years and a day out isn't something that is a concern.
There is a lot of "development team did it, it's done, throw it over the wall and let the maintenance team deal with it." The maintenance team, however, is under resourced and since there aren't any good tests for the functionality, refactoring anything that isn't verifiable is much more work than fixing a bug where you can say "yep, that's done."
Management in many places isn't concerned about code quality and see it more as "developers are gold plating that project." Spending 4h to reduce the time it takes to do a hypothetical support ticket that may never occur from 3h to 1h of maintenance time (that's a different team) isn't a good investment of time.
And while there are enlightened managers out there, they are still up against the metrics of "how much did your team accomplish that the business wanted?"