4 ms·

I agree that further work is unavoidable in an ever changing environment. Software is built over time with the environment constantly shifting under it, it's a

I agree that further work is unavoidable in an ever changing environment. Software is built over time with the environment constantly shifting under it, it's a cycle to maintain and extend (constant changes if you will). That's the crux of why technical debt doesn't exist, or is not a receivable term. If it were debt there should be a way not to take it, but there isn't. Every variable and function and design decision will invariably be rebranded as technical debt by the next developer soon enough. That's not reasonable. One solution to not have debt may be to not write anything, that's not receivable because then there would no product and no company. The other implication is that there may be a perfect state to reach with no debt, but that's not the case, realistically it's not possible to start from code that's perfect and bug free and supports every (future) feature in the universe.

gjulianm 6y ago
> I agree that further work is unavoidable in an ever changing environment. But can definitely be reduced. If my company plans on delivering version 1.0 with feature X, and version 2.0 with feature Y, I can either do an ad-hoc solution for X that will require less work but will need to be changed to allow Y in the future, or I can do some extra work now to reduce the total amount of work I need to do. Those kind of decisions are made quite frequently while programming. Being conscious of them is important in order to understand better the project and the costs of maintenance and new features. > Every variable and function and design decision will invariably be rebranded as technical debt by the next developer soon enough. That's not reasonable. This is not a problem regarding the concept, it's a problem of the specific developer. Just because some people misuse a concept doesn't mean it's useless. But you talk about technical debt as if it's necessarily bad. It's not bad. Some technical debt never needs to be repaid because the product is removed, or because that part is never touched and works well enough. Some technical debt generates so little extra work that it's worth it. But it's important to not scrub that concept, because, as I said, it's important to know the technical debt in a product so that we can better understand the costs of making changes and doing maintenance.
- user5994461 6y ago
  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.
  - gjulianm 6y ago
    > 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.
mytailorisrich 6y ago
Doing the best one can with the information available at that moment may not be 'technical debt'. But I think the analogy fits well when people either cut corners in order to save time now, especially, or, still, when people design something less generic now because there is no need to over-engineer things 'in case'. The latter, and deciding on it, is a form of risk management. The former really is "borrow now/pay later". Claiming that technical debt does not exist fails to try to understand the analogy, imho.

gjulianm 6y ago

> I agree that further work is unavoidable in an ever changing environment. But can definitely be reduced. If my company plans on delivering version 1.0 with feature X, and version 2.0 with feature Y, I can either do an ad-hoc solution for X that will require less work but will need to be changed to allow Y in the future, or I can do some extra work now to reduce the total amount of work I need to do. Those kind of decisions are made quite frequently while programming. Being conscious of them is important in order to understand better the project and the costs of maintenance and new features. > Every variable and function and design decision will invariably be rebranded as technical debt by the next developer soon enough. That's not reasonable. This is not a problem regarding the concept, it's a problem of the specific developer. Just because some people misuse a concept doesn't mean it's useless. But you talk about technical debt as if it's necessarily bad. It's not bad. Some technical debt never needs to be repaid because the product is removed, or because that part is never touched and works well enough. Some technical debt generates so little extra work that it's worth it. But it's important to not scrub that concept, because, as I said, it's important to know the technical debt in a product so that we can better understand the costs of making changes and doing maintenance.

user5994461 6y ago
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.
- gjulianm 6y ago
  > 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.

mytailorisrich 6y ago

Doing the best one can with the information available at that moment may not be 'technical debt'. But I think the analogy fits well when people either cut corners in order to save time now, especially, or, still, when people design something less generic now because there is no need to over-engineer things 'in case'. The latter, and deciding on it, is a form of risk management. The former really is "borrow now/pay later". Claiming that technical debt does not exist fails to try to understand the analogy, imho.