Indeed I've never seen debt in a sense that wasn't considered bad. That's what developers invoke to say everything done by their predecessor was shit. That's what developers claim to rewrite or to jump ship endlessly. All while management is clueless to it because it's all made up in the engineers mind.
How does one go about promoting (fixing) technical debt, or ask for time to fix technical debt, or plan for technical debt in a roadmap or an end of year performance review. That doesn't work.
I do think companies and developers should drop the idea of debt entirely. Consider a more positive model where software development is a cycle to maintain and to extend. Maybe maintenance can put more emphasis on keeping things working and in good conditions.
I've worked for many years on many things from startup to finance to aerospace (this may include planes you fly in and the bank you use). Software is eating the world a bit more every day. The only consistent experience is how companies and developers have zero vision and incentive to keep software running smoothly. The closest thing is a recurrent mention of debt, more often than not as an excuse to refactor or throw away anything.
> All while management is clueless to it because it's all made up in the engineers mind.
Saying that technical debt is made up is not a very productive approach. It's very real and programmers make the trade-off between less work now and less work in the future every day, sometimes consciously, sometimes unconsciously, sometimes because of lack of knowledge. It's useful to have a name for that and to understand it.
I've been programming for a few years already and being conscious of the concept of technical debt and when I incur on it when creating software helps me a lot by improving the decisions I make, by leaving better documentation on the technical debt used and possible fixes, and by being able to communicate better the risks and costs of certain approaches when deadlines are tight.
> How does one go about promoting (fixing) technical debt, or ask for time to fix technical debt, or plan for technical debt in a roadmap or an end of year performance review. That doesn't work.
I've done all these things.
- I've said multiple times to my superiors that implementing a certain feature in a short amount of time would add yet more debt to a certain part of a project, and that it might be better to invest more time to refactor code and add that feature with better code. That led to discussions on whether it was worth it or not depending on the possibilities of similar features being added. Sometimes we did the refactor, sometimes we did the hack. But we were conscious of the decision and the consequences.
- I've taken advantage of periods of low stress to ask for refactors instead of new features, arguing that those refactors would reduce future maintenance and development costs, or reduce bugs in certain fragile parts.
- When discussing roadmaps, I have explained that we can shorten certain stages with technical debt, at the cost of lengthening others to fix that debt, and we have discussed the trade-offs of both approaches.
In all of those situations, being conscious of technical debt allowed me to communicate better the costs associated with maintenance and development and enabled better discussions with management on what to do.
> Consider a more positive model where software development is a cycle to maintain and to extend. Maybe maintenance can put more emphasis on keeping things working and in good conditions.
I agree. That's why I think that the concept of technical debt, correctly used, leads to better understanding of the costs of maintenance and extension and enables better decisions.
> The only consistent experience is how companies and developers have zero vision and incentive to keep software running smoothly. The closest thing is a recurrent mention of debt, more often than not as an excuse to refactor or throw away anything.
But this is a management and culture problem, not a problem of concepts. I don't think that removing useful concepts from our toolbox fixes that. I think that the "not-invented-here" or "not-invented-by-me" syndromes predate the widespread understanding of technical debt.
How does one go about promoting (fixing) technical debt, or ask for time to fix technical debt, or plan for technical debt in a roadmap or an end of year performance review. That doesn't work.
I do think companies and developers should drop the idea of debt entirely. Consider a more positive model where software development is a cycle to maintain and to extend. Maybe maintenance can put more emphasis on keeping things working and in good conditions.
I've worked for many years on many things from startup to finance to aerospace (this may include planes you fly in and the bank you use). Software is eating the world a bit more every day. The only consistent experience is how companies and developers have zero vision and incentive to keep software running smoothly. The closest thing is a recurrent mention of debt, more often than not as an excuse to refactor or throw away anything.