4 ms·

This is absolutely critical to achieve sustainable development in large code bases. However, it is also important to know how to pick your battles. Make the c

This is absolutely critical to achieve sustainable development in large code bases. However, it is also important to know how to pick your battles. Make the change easy with the critical path and core of the system. But sometimes, especially along the periphery, the right choice is to just make the change and be okay with perpetuating a bad pattern, if it is going to bring disproportionate business value quickly. The key is knowing when to take one approach or the other.

omegalulw 4y ago
> But sometimes, especially along the periphery, the right choice is to just make the change and be okay with perpetuating a bad pattern, if it is going to bring disproportionate business value quickly Agreed. Also tests - if the tests are catching the cases they are supposed to but have anti patterns in the way they are written - it's not always worth it to fix them so long as your new test cases can be easily covered.
wpietri 4y ago
I would add one more conditional to this: > just make the change and be okay with perpetuating a bad pattern, if it is going to bring disproportionate business value quickly ... and if it gets cleaned up eventually. Technical debt should be managed like credit card debt. Absolutely take it on in emergencies, but build the discipline of paying it down when the emergency has passed.
- Archelaos 4y ago
  I disagree. It should be only cleaned up, if nothing else is more important.
  - apalmer 4y ago
    I think there is a minimum floor that should be allocated to this kind of work. It doesn’t make sense to clean everything to a perfect condition but there should be some amount of ‘keep your room clean’ level of hygiene that’s maintained
    - Archelaos 4y ago
      I think "cleaning up x" should just be handled as any other to-do-list item. That means evaluating its cost and benefits in context with the other items on the list. Then do what is on position one, then on position two, then on position three, ... Re-evaluate the list from time to time.
      - wpietri 4y ago
        Fine in theory, but often bad in practice, because in a lot of places prioritization is done by people with little or no technical background and lots of incentive to show progress. There are a lot of ways to do this, but my general preference is a black budget plus explicit "credit card" usage. E.g., the team has high standards for any new feature work and quietly spends 15% of their time every week on continuous technical improvement. If the product manager wants to break the normal standards and take on technical debt (e.g., rush have feature X ready for trade show), then you break the work into "rush to add feature X" and "clean up feature X mess". The first gets done before the trade show, the second after. And personally, if a product manager doesn't honor the deal, I say they get their credit card taken away for a while, because they've proven they can't be trusted to do right by the team and the company.
        Archelaos 4y ago
        Actually, I have an explicit agreement that I can spent around 10% of my time on issues of my choice, without having to check with the management. And sometimes, for bigger refactoring work, I have negotiated explicit to-do-list items. On the other side, in the process of re-evaluating the to-dos, I myself often recommend to postpone refactoring when I see the need for implementing a certain feature fast or when I have the impression that the code quality is "good enough" for the moment. Since management trusts me that I can appreciate the business perspective as well, I actually have little trouble asserting myself when I think a particular refactoring issue should be prioritized. So in my case, it works in practice.
        wpietri 4y ago
  - wpietri 4y ago
    On the one hand, that's trivially true and I agree. In which case, I'm saying that keeping debt low is pretty important. On the other, it's a statement that executive priorities mostly trump technical priorities, which I deeply disagree with. Executives generally have a poor understanding of how technical debt works over the long term: https://web.archive.org/web/20190709091156/http://agilefocus.com:80/2009/06/22/the-3-kinds-of-code/ https://web.archive.org/web/20190709091156/http://agilefocus... Week to week, many will say, "OMG, this feature is way more important than technical debt". But year to year, they will say, "Why is it so hard to get anything done here?!? Why is our stuff so buggy?!? We must have terrible developers!" Which is both a management failure and a failure of developers to maintain professional standards. The first is mostly out of our control, but the second is up to us.
    - Archelaos 4y ago
      I just do not think that there is anything magic about what some people call "technical debt" (but I prefer to call a "code smell", since how debt works fundamtentally is quite different from people's typical conclusions around "technical debt"). Eliminating a particular code smell is like any other improvement to an application, but with a special focus on its lifecycle and the associated costs and benefits. And there are opportunity costs: Fixing a particular code smell means that future features of the application will get delayed. And the question is not only at what point in the future, in some (YAGNI) cases perhaps never, our now improved code quality let us catch up with otherwise earlier feature implementations: The extended time-to-market for our new features also comes at a price. So to decide what is actually best, it is not enough to look only at the technical side of a software project. The time-to-market (or time-to-use) cost, which has nothing to do with engineering per se, must also be taken into account. When deciding when a particular code smell should be fixed, both technical and business aspects are important: Technical effort and benefit must be evaluated and weighed against the aforementioned opportunity costs of feature delays. That is why good cooperation and open communication between engineers and business people within a company is important. If this is not the case, well, this is another smell that perhaps needs to be refactored first. If it is worthwhile ...
      - 4y ago
- eru 4y ago
  > Technical debt should be managed like credit card debt. Absolutely take it on in emergencies, but build the discipline of paying it down when the emergency has passed. Technical debt is a misnomer. It's a bit more like 'technical equity'. It's more equity like in that it doesn't have a fixed interest rate. And if the project your 'technical debt' sits on becomes less valuable, so does the value of dealing with the tech debt. But I am not sure comparing code smells to concepts in finance is necessarily a good idea.
  - Nemi 4y ago
    I would agree that it doesn’t have a fixed interest rate. But you might say it has a variable interest rate. The trick is to accurately gauge the true interest rate and only work on the technical debt that costs you over time. The real tricky technical debt is the one that has a small cost, but accrues frequently. At any given time it is easy to tell yourself “this doesn’t cost much and would take me 10 times as long to rewrite than to just make this quick fix”. But if you (or more likely other people) have to keep paying that cost dozens, hundreds, or even thousands of times in the future, then the right decision is to schedule some time to take care of the debt.
  - wpietri 4y ago
    No metaphor is perfect. Note that a lot of debt doesn't have fixed interest rates. And the value of dealing with regular debt also declines when the asset price drops, which is one way we get corporate bankruptcies. Possible imperfections aside, the question is whether the metaphor is useful. I've found it very helpful dealing with business-educated but non-technical stakeholders, because it can get them from the "just keep cramming features in" mindset to understanding that code quality has business implications, and isn't just devs being prima donnas. If you have other ways to get that mentality shift, do tell!
Nemi 4y ago
Human communication is a funny thing. We use phrases like “technical debt is bad” and everyone in the room will nod their heads and be in total agreement, but every single person in that room has a different definition of what technical debt is. To some people it means “buggy code”. To others it means “not the way I would have written it”. Yet to others it means “code that is hard to understand”. What it means to me could be any one of those things, but the defining factor is that there is an ongoing ‘cost’ to the code in question. What kind of cost? Usually time-based cost. It takes someone’s time to manage and handle the situation. It could be that the code causes data inconsistencies that have to be managed by hand occasionally. It could be that frequently updated code takes 100 times as long to change as it should. It could be that the code has grown in complexity to the point that I can’t put a junior developer on it, requiring expensive personnel to maintain. It could be that it compromises the user experience, hampering user adoption. In all of these cases, the underlying is that it costs money. Like true debt does. Which is why using the term “debt” is a perfect description. I would argue that if a piece of code is clunky, buggy, or poorly written, but has no clear impact on the business in any way, is it truly technical debt? One might argue that the person making the decision to write it that way made a pretty valuable business decision. It is like a 0% loan. Until that loan starts costing you money, you would be a fool to spend time paying it off.

omegalulw 4y ago

> But sometimes, especially along the periphery, the right choice is to just make the change and be okay with perpetuating a bad pattern, if it is going to bring disproportionate business value quickly Agreed. Also tests - if the tests are catching the cases they are supposed to but have anti patterns in the way they are written - it's not always worth it to fix them so long as your new test cases can be easily covered.

wpietri 4y ago

I would add one more conditional to this: > just make the change and be okay with perpetuating a bad pattern, if it is going to bring disproportionate business value quickly ... and if it gets cleaned up eventually. Technical debt should be managed like credit card debt. Absolutely take it on in emergencies, but build the discipline of paying it down when the emergency has passed.

Archelaos 4y ago
I disagree. It should be only cleaned up, if nothing else is more important.
- apalmer 4y ago
  I think there is a minimum floor that should be allocated to this kind of work. It doesn’t make sense to clean everything to a perfect condition but there should be some amount of ‘keep your room clean’ level of hygiene that’s maintained
  - Archelaos 4y ago
    I think "cleaning up x" should just be handled as any other to-do-list item. That means evaluating its cost and benefits in context with the other items on the list. Then do what is on position one, then on position two, then on position three, ... Re-evaluate the list from time to time.
    - wpietri 4y ago
      Fine in theory, but often bad in practice, because in a lot of places prioritization is done by people with little or no technical background and lots of incentive to show progress. There are a lot of ways to do this, but my general preference is a black budget plus explicit "credit card" usage. E.g., the team has high standards for any new feature work and quietly spends 15% of their time every week on continuous technical improvement. If the product manager wants to break the normal standards and take on technical debt (e.g., rush have feature X ready for trade show), then you break the work into "rush to add feature X" and "clean up feature X mess". The first gets done before the trade show, the second after. And personally, if a product manager doesn't honor the deal, I say they get their credit card taken away for a while, because they've proven they can't be trusted to do right by the team and the company.
      - Archelaos 4y ago
        Actually, I have an explicit agreement that I can spent around 10% of my time on issues of my choice, without having to check with the management. And sometimes, for bigger refactoring work, I have negotiated explicit to-do-list items. On the other side, in the process of re-evaluating the to-dos, I myself often recommend to postpone refactoring when I see the need for implementing a certain feature fast or when I have the impression that the code quality is "good enough" for the moment. Since management trusts me that I can appreciate the business perspective as well, I actually have little trouble asserting myself when I think a particular refactoring issue should be prioritized. So in my case, it works in practice.
        wpietri 4y ago
- wpietri 4y ago
  On the one hand, that's trivially true and I agree. In which case, I'm saying that keeping debt low is pretty important. On the other, it's a statement that executive priorities mostly trump technical priorities, which I deeply disagree with. Executives generally have a poor understanding of how technical debt works over the long term: https://web.archive.org/web/20190709091156/http://agilefocus.com:80/2009/06/22/the-3-kinds-of-code/ https://web.archive.org/web/20190709091156/http://agilefocus... Week to week, many will say, "OMG, this feature is way more important than technical debt". But year to year, they will say, "Why is it so hard to get anything done here?!? Why is our stuff so buggy?!? We must have terrible developers!" Which is both a management failure and a failure of developers to maintain professional standards. The first is mostly out of our control, but the second is up to us.
  - Archelaos 4y ago
    I just do not think that there is anything magic about what some people call "technical debt" (but I prefer to call a "code smell", since how debt works fundamtentally is quite different from people's typical conclusions around "technical debt"). Eliminating a particular code smell is like any other improvement to an application, but with a special focus on its lifecycle and the associated costs and benefits. And there are opportunity costs: Fixing a particular code smell means that future features of the application will get delayed. And the question is not only at what point in the future, in some (YAGNI) cases perhaps never, our now improved code quality let us catch up with otherwise earlier feature implementations: The extended time-to-market for our new features also comes at a price. So to decide what is actually best, it is not enough to look only at the technical side of a software project. The time-to-market (or time-to-use) cost, which has nothing to do with engineering per se, must also be taken into account. When deciding when a particular code smell should be fixed, both technical and business aspects are important: Technical effort and benefit must be evaluated and weighed against the aforementioned opportunity costs of feature delays. That is why good cooperation and open communication between engineers and business people within a company is important. If this is not the case, well, this is another smell that perhaps needs to be refactored first. If it is worthwhile ...
    - 4y ago
eru 4y ago
> Technical debt should be managed like credit card debt. Absolutely take it on in emergencies, but build the discipline of paying it down when the emergency has passed. Technical debt is a misnomer. It's a bit more like 'technical equity'. It's more equity like in that it doesn't have a fixed interest rate. And if the project your 'technical debt' sits on becomes less valuable, so does the value of dealing with the tech debt. But I am not sure comparing code smells to concepts in finance is necessarily a good idea.
- Nemi 4y ago
  I would agree that it doesn’t have a fixed interest rate. But you might say it has a variable interest rate. The trick is to accurately gauge the true interest rate and only work on the technical debt that costs you over time. The real tricky technical debt is the one that has a small cost, but accrues frequently. At any given time it is easy to tell yourself “this doesn’t cost much and would take me 10 times as long to rewrite than to just make this quick fix”. But if you (or more likely other people) have to keep paying that cost dozens, hundreds, or even thousands of times in the future, then the right decision is to schedule some time to take care of the debt.
- wpietri 4y ago
  No metaphor is perfect. Note that a lot of debt doesn't have fixed interest rates. And the value of dealing with regular debt also declines when the asset price drops, which is one way we get corporate bankruptcies. Possible imperfections aside, the question is whether the metaphor is useful. I've found it very helpful dealing with business-educated but non-technical stakeholders, because it can get them from the "just keep cramming features in" mindset to understanding that code quality has business implications, and isn't just devs being prima donnas. If you have other ways to get that mentality shift, do tell!

Nemi 4y ago

Human communication is a funny thing. We use phrases like “technical debt is bad” and everyone in the room will nod their heads and be in total agreement, but every single person in that room has a different definition of what technical debt is. To some people it means “buggy code”. To others it means “not the way I would have written it”. Yet to others it means “code that is hard to understand”. What it means to me could be any one of those things, but the defining factor is that there is an ongoing ‘cost’ to the code in question. What kind of cost? Usually time-based cost. It takes someone’s time to manage and handle the situation. It could be that the code causes data inconsistencies that have to be managed by hand occasionally. It could be that frequently updated code takes 100 times as long to change as it should. It could be that the code has grown in complexity to the point that I can’t put a junior developer on it, requiring expensive personnel to maintain. It could be that it compromises the user experience, hampering user adoption. In all of these cases, the underlying is that it costs money. Like true debt does. Which is why using the term “debt” is a perfect description. I would argue that if a piece of code is clunky, buggy, or poorly written, but has no clear impact on the business in any way, is it truly technical debt? One might argue that the person making the decision to write it that way made a pretty valuable business decision. It is like a 0% loan. Until that loan starts costing you money, you would be a fool to spend time paying it off.