3 ms·

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.

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.