[galaxyLogic]

I think what could help is using JIRA -like issues-reporting system dedicated not to publicly observable problems ("bugs") with the software application, but internal code-design issues which can be seen to possibly cause detrimental issues with software maintenance later. In other words issues which can be categorized as technical debt.

Technically this could be implemented using the same software that is used for bug-reporting.

Then would developers willingly report issues to such a system? I think they would because solving such issues is satisfying to whoever cares about software quality, because it makes it easier to maintain the system in the future.

From a developer's perspective the worst kind of assignment is to try to fix something in a very fragile system because if they "break it, they own it". Therefore developers love SW quality.

But would management approve of spending time on reporting and possibly fixing design issues? Well why not because if the knowledge of the issues exists only in the head of some developers, it is not really owned by the company. Whereas if it was reported in an issue-tracking system it would become official part of the IP owned by the company, increasing its value. So yes I think at least some enlightened managers would approve the use of such a system.

Using such a system would seem to make a lot of sense to me. Perhaps companies are already doing it?

[shagie]

(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?"

[galaxyLogic]

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.

[shagie]

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).

I occasionally think about how to implement PEF/REV ( https://www.fincher.org/tips/General/SoftwareDevelopment/Bug... - though https://lostgarden.home.blog/2008/05/20/improving-bug-triage... is another approach) in Jira (long ago, I was part way through implementing it as a plugin in Redline).

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.

[galaxyLogic]

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

[quanticle]

    But would management approve of spending time on reporting and possibly
    fixing design issues? Well why not because if the knowledge of the issues
    exists only in the head of some developers, it is not really owned by the
    company. Whereas if it was reported in an issue-tracking system it would
    become official part of the IP owned by the company, increasing its value.

In practice, management will not endorse developers reporting and spending time working on design issues, unless that design issue can be directly identified as a blocker impeding the delivery of urgently needed functionality. Even then, half the time the developer will be told to note the issue and implement a short-term workaround.

    Using such a system would seem to make a lot of sense to me. Perhaps
    companies are already doing it?

Pretty much every company I've worked for has had a category in JIRA for design issues and technical debt. Tracking these things isn't the problem. The problem is getting buy-in to spend a portion of each sprint actually addressing these issues, rather than having them in some backlog pile that everyone pays lip service to, but no one takes action on actually reducing.