4 ms·

On the contrary, software should rarely ever be rewritten from scratch. Rewriting existing software both is incredibly risky from a business perspective and po

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).
    - lmm 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. I've seen it happen, once. Almost two years of work, lots of architecture, design and all that. Built a beautiful codebase that implemented a product that noone actually wanted. It was a positive experience in some ways, but not something I want to see again.
    - zbentley 9y ago
      > the reason it turned legacy in the first place was because insufficient resources didn't allow proper maintenance. I want to get that on a T shirt, a placard, an ad campaign, and a billboard.
FLUX-YOU 9y ago
>jeopardises the hard-won knowledge from years of working on and working with the software We have issue trackers and robust source control these days, that's not really true unless someone wrote poor commit messages and didn't write anything on the issue. You can roll that into the new specs if you take the time to document. Knowledge preserved. The only hard-won knowledge you should be fighting for is business knowledge, which can be dependent on your UI/UX decisions. If you rewrite and change that substantially, yes, you lose that knowledge because you've obviously changed the UI/UX. You now force all of your users to relearn your product. Plus, you're going to get a whole new category of bugs with that new UI/UX. All of this was made more difficult back then by not having the modern language features in stuff like Rust and .NET and Go and Python that's made stuff easier and safer. Rewriting .NET -> .NET is much, much easier than C -> C. If you change languages, that's worse, and you'd have to completely learn two languages and all of their painful/weird points AND translate between those two (if you thought JavaScript equality was bad...)

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).
  - lmm 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. I've seen it happen, once. Almost two years of work, lots of architecture, design and all that. Built a beautiful codebase that implemented a product that noone actually wanted. It was a positive experience in some ways, but not something I want to see again.
  - zbentley 9y ago
    > the reason it turned legacy in the first place was because insufficient resources didn't allow proper maintenance. I want to get that on a T shirt, a placard, an ad campaign, and a billboard.

FLUX-YOU 9y ago

>jeopardises the hard-won knowledge from years of working on and working with the software We have issue trackers and robust source control these days, that's not really true unless someone wrote poor commit messages and didn't write anything on the issue. You can roll that into the new specs if you take the time to document. Knowledge preserved. The only hard-won knowledge you should be fighting for is business knowledge, which can be dependent on your UI/UX decisions. If you rewrite and change that substantially, yes, you lose that knowledge because you've obviously changed the UI/UX. You now force all of your users to relearn your product. Plus, you're going to get a whole new category of bugs with that new UI/UX. All of this was made more difficult back then by not having the modern language features in stuff like Rust and .NET and Go and Python that's made stuff easier and safer. Rewriting .NET -> .NET is much, much easier than C -> C. If you change languages, that's worse, and you'd have to completely learn two languages and all of their painful/weird points AND translate between those two (if you thought JavaScript equality was bad...)