4 ms·

This is mentioned in the article as possible only for small changes. When the refactoring involves more systemic problems, it becomes impossible to make the cha

This is mentioned in the article as possible only for small changes. When the refactoring involves more systemic problems, it becomes impossible to make the change in the course of making other client-facing changes. I'll add that some subsystems are a mess but stable. It's difficult to make refactorings with other changes when there aren't other changes to make. I see this in particular with old but stable subsystems that will need to be ported to new environments someday, but it's never a good day to lay the groundwork for that inevitable change.

lmm 10y ago
> I see this in particular with old but stable subsystems that will need to be ported to new environments someday, but it's never a good day to lay the groundwork for that inevitable change. I think it's correct to defer that work until you need it. You may end up never porting that subsystem, in which case refactoring the currently-stable implementation is wasted effort. As and when porting becomes an actual business requirement it can be prioritized appropriately.
- humanrebar 10y ago
  > You may end up never porting that subsystem, in which case refactoring the currently-stable implementation is wasted effort. I understand this approach, and it works many times. But when the porting is delayed until the last possible minute, it's more likely that hacks are put in because the requirement turned into a hard deadline. Instead of defining a sensible OS abstraction layer, the developers might find and replace "Windows XP" with "Windows 7".
  - lmm 10y ago
    > I understand this approach, and it works many times. But when the porting is delayed until the last possible minute, it's more likely that hacks are put in because the requirement turned into a hard deadline. Instead of defining a sensible OS abstraction layer, the developers might find and replace "Windows XP" with "Windows 7". Which may well be the right choice for the business at that point. More generally, it's not like doing it now makes it faster than doing it later: you have to put the same amount of total work in either way. In fact you have to put more work in if you do it now, because you will have to ensure that any subsequent changes don't break the porting. If you have other tasks that are a higher priority than porting, you should do them first, almost by definition. Of course if the port is your highest priority then that is what you should be working on (again almost by definition). Porting should be left as late as possible, but no later.
    - humanrebar 10y ago
      You misunderstand. If more than a small minority of your code cares what OS it's running on (beyond obvious excepted), you have a large amount of technical debt. Cleaning that up, either by refactoring or replacing the offending code, is in the business's best interest because it keeps costs down and keeps more options available to the business. The 'business people' are not qualified by themselves to say that the cost-benefit analysis of the refactoring is worth the effort. Because while they may have a good idea of the customer benefits, they generally have little insight into what the future costs of technical debt are. You see this obviously demonstrated by 'business people' who are shocked that there is work to do on five-year-old code that has been working fine for years. Any reasonably experienced developer, any many junior developers besides, can tell you that code rots if it's not maintained properly.
      - lmm 10y ago
        > Cleaning that up, either by refactoring or replacing the offending code, is in the business's best interest because it keeps costs down and keeps more options available to the business. IME that's very rarely the highest-value thing you can be doing for the business. It's not worth paying for flexibility that you're never going to use, and it's not like it's going to take longer to refactor later than it would to do it now. > The 'business people' are not qualified by themselves to say that the cost-benefit analysis of the refactoring is worth the effort. Yes they are. Cost-benefit analysis is their job. It's your job to give them an accurate picture of the costs and the benefits. > Because while they may have a good idea of the customer benefits, they generally have little insight into what the future costs of technical debt are. You see this obviously demonstrated by 'business people' who are shocked that there is work to do on five-year-old code that has been working fine for years. Any reasonably experienced developer, any many junior developers besides, can tell you that code rots if it's not maintained properly. Yes and no. If you don't need to make changes to a given system then it's fine for it to "rot". Presumably there is a business reason they want to make changes, in which case bringing the code up to a point where you can make those changes is part of the cost of that business-level deliverable.
        10y ago

lmm 10y ago

> I see this in particular with old but stable subsystems that will need to be ported to new environments someday, but it's never a good day to lay the groundwork for that inevitable change. I think it's correct to defer that work until you need it. You may end up never porting that subsystem, in which case refactoring the currently-stable implementation is wasted effort. As and when porting becomes an actual business requirement it can be prioritized appropriately.

humanrebar 10y ago
> You may end up never porting that subsystem, in which case refactoring the currently-stable implementation is wasted effort. I understand this approach, and it works many times. But when the porting is delayed until the last possible minute, it's more likely that hacks are put in because the requirement turned into a hard deadline. Instead of defining a sensible OS abstraction layer, the developers might find and replace "Windows XP" with "Windows 7".
- lmm 10y ago
  > I understand this approach, and it works many times. But when the porting is delayed until the last possible minute, it's more likely that hacks are put in because the requirement turned into a hard deadline. Instead of defining a sensible OS abstraction layer, the developers might find and replace "Windows XP" with "Windows 7". Which may well be the right choice for the business at that point. More generally, it's not like doing it now makes it faster than doing it later: you have to put the same amount of total work in either way. In fact you have to put more work in if you do it now, because you will have to ensure that any subsequent changes don't break the porting. If you have other tasks that are a higher priority than porting, you should do them first, almost by definition. Of course if the port is your highest priority then that is what you should be working on (again almost by definition). Porting should be left as late as possible, but no later.
  - humanrebar 10y ago
    You misunderstand. If more than a small minority of your code cares what OS it's running on (beyond obvious excepted), you have a large amount of technical debt. Cleaning that up, either by refactoring or replacing the offending code, is in the business's best interest because it keeps costs down and keeps more options available to the business. The 'business people' are not qualified by themselves to say that the cost-benefit analysis of the refactoring is worth the effort. Because while they may have a good idea of the customer benefits, they generally have little insight into what the future costs of technical debt are. You see this obviously demonstrated by 'business people' who are shocked that there is work to do on five-year-old code that has been working fine for years. Any reasonably experienced developer, any many junior developers besides, can tell you that code rots if it's not maintained properly.
    - lmm 10y ago
      > Cleaning that up, either by refactoring or replacing the offending code, is in the business's best interest because it keeps costs down and keeps more options available to the business. IME that's very rarely the highest-value thing you can be doing for the business. It's not worth paying for flexibility that you're never going to use, and it's not like it's going to take longer to refactor later than it would to do it now. > The 'business people' are not qualified by themselves to say that the cost-benefit analysis of the refactoring is worth the effort. Yes they are. Cost-benefit analysis is their job. It's your job to give them an accurate picture of the costs and the benefits. > Because while they may have a good idea of the customer benefits, they generally have little insight into what the future costs of technical debt are. You see this obviously demonstrated by 'business people' who are shocked that there is work to do on five-year-old code that has been working fine for years. Any reasonably experienced developer, any many junior developers besides, can tell you that code rots if it's not maintained properly. Yes and no. If you don't need to make changes to a given system then it's fine for it to "rot". Presumably there is a business reason they want to make changes, in which case bringing the code up to a point where you can make those changes is part of the cost of that business-level deliverable.
      - 10y ago