4 ms·

Right, and ensure you never can fix anything and hire generations of people who slave over the old crappola until they give up. Meanwhile you wind up with legac

Right, and ensure you never can fix anything and hire generations of people who slave over the old crappola until they give up. Meanwhile you wind up with legacy code from multiple languages/language versions all mixed up like a junkyard sculpture. I worked at a major travel company (you know the brand) that ignored its legacy web+backend for almost 10 years until our parent company basically gave us away to our biggest competitor (the tech was all abandoned as unusable) who made us just a marketing brand (also 100% of people laid off in the process). We couldn't keep up with our competitors as everything was impossible to fix any more. On the other hand the mobile team I worked with replaced everything and we were extremely agile in competing (other than being limited by the crappy back end). It's not always a good idea to replace everything, but it's also not a good idea to live with shit either.

hn_throwaway_99 7y ago
My thoughts (as someone who worked at a brand of the same parent travel company as you): It is definitely NOT a good idea to live with shit as it will kill your velocity long term, so the question is how to replace it? Every single "big bang" replacement I've done, while not exactly a total failure, was extremely painful. If a tool like this made it easier to piecemeal replace your legacy code, while showing business value more incrementally, I'd be all for it. I agree leaving your house in this "junkyard sculpture" state indefinitely (love that analogy) will eventually kill your business.
- lowercased 7y ago
  > Every single "big bang" replacement I've done, while not exactly a total failure, was extremely painful. The bigger question might be how much more painful was it than continuing to try to be competitive (react with new functionality, deliver ongoing value, etc) in the previous codebase, and how much more painful over trying to plan out small incremental refactoring changes during the same time? And... after a certain time period of going through that pain, was the end result quantifiably more useful (testable, fewer bugs, faster, easier to grok/extend/etc - choose your metrics) than if that big change wasn't undertaken?
- hinkley 7y ago
  I think the problem here is that we often ask the questions too late. Things went wrong a very long time ago. A rewrite is declaring bankruptcy, but often the same actors barely change their behavior and you end up in the exact same spot again. I’m starting to fear that the right response, especially considering the Big Picture, is to let it die. Let some other competitor with fresh ideas eat your lunch. I suspect these problems are symptoms of a deeper, terminal illness and palliative care is the best you can do.
- JMTQp8lwXL 7y ago
  I agree. I've worked at a company where the plan to migrate from a legacy system to the green architecture was planned to take a decade. With large systems, you will always be in a state of flux. It's simply impossible to replace the entire system in one swoop. Libraries like this acknowledge the incremental nature of accepting a migration path over time.
hinkley 7y ago
I had an experience like this early in my career and for a very long time I fought to avoid this by insisting that there is a world of difference between learning to work faster (through craft and mastery) versus faking it. You see this in sports, where one team is ahead and loses in the final minutes because they have ground themselves down. The other team wins on stamina. But the number of people who want to hear this is depressingly low. It’s more common in younger people, but they have no clout, so I get mentees easily enough, but they take a long time to become allies. The places I look back on fondly, I had a boss who agreed, but often their skip level boss was having none of it, so the work was still... well, work.

hn_throwaway_99 7y ago

My thoughts (as someone who worked at a brand of the same parent travel company as you): It is definitely NOT a good idea to live with shit as it will kill your velocity long term, so the question is how to replace it? Every single "big bang" replacement I've done, while not exactly a total failure, was extremely painful. If a tool like this made it easier to piecemeal replace your legacy code, while showing business value more incrementally, I'd be all for it. I agree leaving your house in this "junkyard sculpture" state indefinitely (love that analogy) will eventually kill your business.

lowercased 7y ago
> Every single "big bang" replacement I've done, while not exactly a total failure, was extremely painful. The bigger question might be how much more painful was it than continuing to try to be competitive (react with new functionality, deliver ongoing value, etc) in the previous codebase, and how much more painful over trying to plan out small incremental refactoring changes during the same time? And... after a certain time period of going through that pain, was the end result quantifiably more useful (testable, fewer bugs, faster, easier to grok/extend/etc - choose your metrics) than if that big change wasn't undertaken?
hinkley 7y ago
I think the problem here is that we often ask the questions too late. Things went wrong a very long time ago. A rewrite is declaring bankruptcy, but often the same actors barely change their behavior and you end up in the exact same spot again. I’m starting to fear that the right response, especially considering the Big Picture, is to let it die. Let some other competitor with fresh ideas eat your lunch. I suspect these problems are symptoms of a deeper, terminal illness and palliative care is the best you can do.
JMTQp8lwXL 7y ago
I agree. I've worked at a company where the plan to migrate from a legacy system to the green architecture was planned to take a decade. With large systems, you will always be in a state of flux. It's simply impossible to replace the entire system in one swoop. Libraries like this acknowledge the incremental nature of accepting a migration path over time.

hinkley 7y ago

I had an experience like this early in my career and for a very long time I fought to avoid this by insisting that there is a world of difference between learning to work faster (through craft and mastery) versus faking it. You see this in sports, where one team is ahead and loses in the final minutes because they have ground themselves down. The other team wins on stamina. But the number of people who want to hear this is depressingly low. It’s more common in younger people, but they have no clout, so I get mentees easily enough, but they take a long time to become allies. The places I look back on fondly, I had a boss who agreed, but often their skip level boss was having none of it, so the work was still... well, work.