5 ms·

I stopped being concerned about this specifically a couple of years ago. Complex software does not need to be refactored, it needs to be rewritten. The importan

I stopped being concerned about this specifically a couple of years ago. Complex software does not need to be refactored, it needs to be rewritten. The important thing that the legacy software does is firm up the domain. With the concepts and language set, rewriting to encapsulate new semantics is relatively easy. It's when you have no idea what the domain is going to look like where it's hard, and that makes for complex, quickly-becoming-legacy code.

emodendroket 9y ago
After all, who's ever heard of a code rewrite getting out of hand and taking way more time than anticipated or even never being finished at all? It's not never the right answer but there are serious risks in doing a rewrite and you'll be stuck supporting two systems for a substantial length of time.
- vinceguidry 9y ago
  Refactoring is never the answer either. Just keeping the legacy system standing until capital becomes free to replace it is what usually happens in my experience.
BjoernKW 9y ago
On the contrary, software should rarely ever be rewritten from scratch. Rewriting existing software both is incredibly risky from a business perspective and potentially jeopardises the hard-won knowledge from years of working on and working with the software (also see Joel Spolsky's take on this: https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ https://www.joelonsoftware.com/2000/04/06/things-you-should-... ). As tedious as it may be sometimes, refactoring software and gradually replacing parts after having written the appropriate tests that make sure the software still works as expected almost always is the better long-term approach to reducing complexity and improving software quality.
- vinceguidry 9y ago
  I'd like to see that happen just once in my career.
  - user5994461 9y ago
    Seen it happen more than once. The new guys throw away the old thing because it's a mess and it's too hard to understand. Two years later, the new new guys throw away the new thing because it's a mess and it's too hard to understand. The company's website is ever new.
    - vinceguidry 9y ago
      No, I meant the scenario where a company listens to the engineers and lets them put off business goals to spend weeks to months every so often refactoring, ending up with a modern, easily-maintained system instead of an arcane mess. My solution to the problem when it was my problem to deal with was LITFA (leave it the fuck alone) until business priorities allow replacing it with a solution that's managed by other people. Obviously the reason it turned legacy in the first place was because insufficient resources didn't allow proper maintenance. Well if maintenance was too hard, rewriting with your maintenance staff certainly won't drive a better outcome. The only way I see either refactoring or rewriting working is if LITFA introduces an existential risk to the company, and the company really, truly, actually does have enough resources on hand to do a proper job of it. But I don't believe anything short of a bet-the-company situation is going to really light a fire under people's asses.
      - user5994461 9y ago
        >>> ending up with a modern, easily-maintained system instead of an arcane mess. This ending never happened, ever. I think I agree about the resource aspect you mention. A lot of the software I've seen was about as good as it could get with the resources that were allocated to it.
      - watwut 9y ago
        I have seen refactorings, but it does not involve putting off business goals. It involved one part of team refactoring a part of codebase while other part of team is producing new features on another part of code, so that at least some business goals are met. You also do it piece by piece, because half done refactoring is worst then none. One potential disadvantage of LIFTA is that you miss learning. Bad legacy code does not happen just because no maintenance, but more often because the original architecture is not suitable for all requirements and it requires hacks. When you (or team) are writing the same thing second time, you write it differently and better then first time. There is also a question of who should do the refactoring - and it should be someone who knows requirements and has good judgement (e.g. not a new junior you barely know).

emodendroket 9y ago

After all, who's ever heard of a code rewrite getting out of hand and taking way more time than anticipated or even never being finished at all? It's not never the right answer but there are serious risks in doing a rewrite and you'll be stuck supporting two systems for a substantial length of time.

vinceguidry 9y ago
Refactoring is never the answer either. Just keeping the legacy system standing until capital becomes free to replace it is what usually happens in my experience.

BjoernKW 9y ago

On the contrary, software should rarely ever be rewritten from scratch. Rewriting existing software both is incredibly risky from a business perspective and potentially jeopardises the hard-won knowledge from years of working on and working with the software (also see Joel Spolsky's take on this: https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ https://www.joelonsoftware.com/2000/04/06/things-you-should-... ). As tedious as it may be sometimes, refactoring software and gradually replacing parts after having written the appropriate tests that make sure the software still works as expected almost always is the better long-term approach to reducing complexity and improving software quality.

vinceguidry 9y ago
I'd like to see that happen just once in my career.
- user5994461 9y ago
  Seen it happen more than once. The new guys throw away the old thing because it's a mess and it's too hard to understand. Two years later, the new new guys throw away the new thing because it's a mess and it's too hard to understand. The company's website is ever new.
  - vinceguidry 9y ago
    No, I meant the scenario where a company listens to the engineers and lets them put off business goals to spend weeks to months every so often refactoring, ending up with a modern, easily-maintained system instead of an arcane mess. My solution to the problem when it was my problem to deal with was LITFA (leave it the fuck alone) until business priorities allow replacing it with a solution that's managed by other people. Obviously the reason it turned legacy in the first place was because insufficient resources didn't allow proper maintenance. Well if maintenance was too hard, rewriting with your maintenance staff certainly won't drive a better outcome. The only way I see either refactoring or rewriting working is if LITFA introduces an existential risk to the company, and the company really, truly, actually does have enough resources on hand to do a proper job of it. But I don't believe anything short of a bet-the-company situation is going to really light a fire under people's asses.
    - user5994461 9y ago
      >>> ending up with a modern, easily-maintained system instead of an arcane mess. This ending never happened, ever. I think I agree about the resource aspect you mention. A lot of the software I've seen was about as good as it could get with the resources that were allocated to it.
    - watwut 9y ago
      I have seen refactorings, but it does not involve putting off business goals. It involved one part of team refactoring a part of codebase while other part of team is producing new features on another part of code, so that at least some business goals are met. You also do it piece by piece, because half done refactoring is worst then none. One potential disadvantage of LIFTA is that you miss learning. Bad legacy code does not happen just because no maintenance, but more often because the original architecture is not suitable for all requirements and it requires hacks. When you (or team) are writing the same thing second time, you write it differently and better then first time. There is also a question of who should do the refactoring - and it should be someone who knows requirements and has good judgement (e.g. not a new junior you barely know).