6 ms·

Maintentance is not technical debt, and confusing both terms is weird. While there are multiple definitions, I'd say maintentance is the work of making adjustme

Maintentance is not technical debt, and confusing both terms is weird. While there are multiple definitions, I'd say maintentance is the work of making adjustments to keep the software in a working state, say supporting new operating systems, fixing bugs, updating to minor versions of libraries... Technical debt, on the other hand, is quite literally a form of debt. You borrow time from the future by developing a solution that requires less work now, but that will need to be changed later on because it won't be enough future requisites, and that will create additional work (interest) in the long term while it's present. And every programmer does this, consciously or unconsciously. Say hard-coding some parameters in functions instead of creating user-defined options because it's easier, or writing a specific class instead of an abstract one that can be later extended, or writing a hack instead of refactoring so that new changes fit properly. Of course, it's difficult to predict the future and some technical debt is never repaid. But it's important to make a distinction and to have in mind the technical debt in your project and when it's worth it to remove it.

mytailorisrich 6y ago
Spot on comment. I'd add that there is also a principle of not trying to predict the future and make design over-general and over-flexible 'just in case', but rather to have the simplest design that fits current requirements (though of course it should be clean and follow good practice). The may lead to technical debt in the future but it may not. The idea being not to spend until you have to. Now, a fudge now to save time should only be done under tight schedule with a plan to fix it later... In an ideal world. I think this is the case that really fits the analogy of borrowing/debt. Overall, technical debt is unavoidable in a ever changing, unpredictable environment
- user5994461 6y ago
  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.
magicalhippo 6y ago
A typical point where you find you have to repay your dept is precisely when you need to perform maintenance. As a concrete example, a previous programmer at work when tasked with adding yet another file format to export would copy the entire code of one of the existing ones, make the necessary changes and ship it. Instead he could have written it from scratch, recognized that "hey, I need to calculate the same sum as in this other exporter, let me refactor that into a separate function and call that" and so on. Then we wouldn't have two dozen pieces of code to check when doing maintenance. Him not spending time to refactor created an additional burden that we now have to repay when performing maintenance, that's the technical dept.
DJHenk 6y ago
> Technical debt, on the other hand, is quite literally a form of debt. You borrow time from the future by developing a solution that requires less work now, but that will need to be changed later on because it won't be enough future requisites, and that will create additional work (interest) in the long term while it's present It is all just a words game. If there is an issue now, and I do a hotfix and hardcode some stuff that surely will need work later on to keep things working, then: A) I created technical debt. I took the quick route now, but will have to spend more time in the future if I want to update this code. B) I did maintenance. A thing was not working and I made it work. This is a simple, small bugfix, a.k.a. maintenance. In the future we might have to spend some time to keep things working in slightly different conditions. We also call that maintenance. Both ways of phrasing it can help to communicate a message. But there is no use in getting hung up on what to call it. Your job as a developer is to be smart about it and choose the best possible trade-off. You need to do that in both versions equally.
- gjulianm 6y ago
  Maintenance and technical debt are intertwined, but I don't think it's just a words game. Things without a name are less visible, and maintenance and technical debt are different. There's maintenance unrelated to technical debt, and technical debt unrelated to maintenance. Taking into account the technical debt you have helps you when estimating the cost of maintenance and new features, or to understand the possible problems when new environments come into play. IMHO, part of being smart about it is having the words to communicate the concepts clearly, it's not a moot discussion.
  - kthejoker2 6y ago
    > There's maintenance unrelated to technical debt, Agreed. > and technical debt unrelated to maintenance Disgareed, as you cheerfully indicate yourself in your next sentence. Technical debt as a concept of "debt" is paid back through maintenance. What else might it be paid back with?
    - gjulianm 6y ago
iamkroot 6y ago
Technical debt is not just limited to programming, either. Consider the cabling in a data center: It's very easy to create a new connection by dragging a cable down the aisle from one device to the other. But do this over and over and you'll be left with a tangled mess that's impossible to maintain, understand, and document. Short quick fixes can be appropriate under the right circumstances, but it's important to go back and clean them up at the earliest opportunity.

mytailorisrich 6y ago

Spot on comment. I'd add that there is also a principle of not trying to predict the future and make design over-general and over-flexible 'just in case', but rather to have the simplest design that fits current requirements (though of course it should be clean and follow good practice). The may lead to technical debt in the future but it may not. The idea being not to spend until you have to. Now, a fudge now to save time should only be done under tight schedule with a plan to fix it later... In an ideal world. I think this is the case that really fits the analogy of borrowing/debt. Overall, technical debt is unavoidable in a ever changing, unpredictable environment

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

magicalhippo 6y ago

A typical point where you find you have to repay your dept is precisely when you need to perform maintenance. As a concrete example, a previous programmer at work when tasked with adding yet another file format to export would copy the entire code of one of the existing ones, make the necessary changes and ship it. Instead he could have written it from scratch, recognized that "hey, I need to calculate the same sum as in this other exporter, let me refactor that into a separate function and call that" and so on. Then we wouldn't have two dozen pieces of code to check when doing maintenance. Him not spending time to refactor created an additional burden that we now have to repay when performing maintenance, that's the technical dept.

DJHenk 6y ago

> Technical debt, on the other hand, is quite literally a form of debt. You borrow time from the future by developing a solution that requires less work now, but that will need to be changed later on because it won't be enough future requisites, and that will create additional work (interest) in the long term while it's present It is all just a words game. If there is an issue now, and I do a hotfix and hardcode some stuff that surely will need work later on to keep things working, then: A) I created technical debt. I took the quick route now, but will have to spend more time in the future if I want to update this code. B) I did maintenance. A thing was not working and I made it work. This is a simple, small bugfix, a.k.a. maintenance. In the future we might have to spend some time to keep things working in slightly different conditions. We also call that maintenance. Both ways of phrasing it can help to communicate a message. But there is no use in getting hung up on what to call it. Your job as a developer is to be smart about it and choose the best possible trade-off. You need to do that in both versions equally.

gjulianm 6y ago
Maintenance and technical debt are intertwined, but I don't think it's just a words game. Things without a name are less visible, and maintenance and technical debt are different. There's maintenance unrelated to technical debt, and technical debt unrelated to maintenance. Taking into account the technical debt you have helps you when estimating the cost of maintenance and new features, or to understand the possible problems when new environments come into play. IMHO, part of being smart about it is having the words to communicate the concepts clearly, it's not a moot discussion.
- kthejoker2 6y ago
  > There's maintenance unrelated to technical debt, Agreed. > and technical debt unrelated to maintenance Disgareed, as you cheerfully indicate yourself in your next sentence. Technical debt as a concept of "debt" is paid back through maintenance. What else might it be paid back with?
  - gjulianm 6y ago

iamkroot 6y ago

Technical debt is not just limited to programming, either. Consider the cabling in a data center: It's very easy to create a new connection by dragging a cable down the aisle from one device to the other. But do this over and over and you'll be left with a tangled mess that's impossible to maintain, understand, and document. Short quick fixes can be appropriate under the right circumstances, but it's important to go back and clean them up at the earliest opportunity.