3 ms·

looking back on it, that was a good candidate for a total rewrite It's virtually impossible to rewrite a large scale application where the only documentation i

looking back on it, that was a good candidate for a total rewrite It's virtually impossible to rewrite a large scale application where the only documentation is the code, especially if the code is bad enough to warrant a rewrite. You will break things, lose features, potentially corrupt data. Total rewrites of unspecified, untestable, poorly understood systems should be the last resort. That said, the system was still running with customers using it 2 and a half years later, which is a very strong signal that it didn't need a rewrite after all. It sounds like you got it right - refactor as you go is usually the best way out of a bad codebase.

quickthrower2 5y ago
A way around this is a side by side test of a lot of the functions. Maybe generate tests form system 1 outputs and use them to test the greenfield system. Where they differ you then decide where the bug is.
- adam_arthur 5y ago
  Yeah this would work very well for certain types of apps. An API would be easy to validate with this approach, for example.
adam_arthur 5y ago
Yeah, definitely a good rule of thumb :) But in this case a total rewrite would have saved time, and improved velocity. Looking back on it. It was impossible to really know at the time, though. Fortunately this project was more presentational than business logic heavy, so missing functionality would have been easy to notice when testing (all visual). I wouldn't agree that running is a sign of success necessarily. There are a lot of running legacy systems that get beaten out and replaced by competitors due to low development velocity. Of course a lot of that comes down to the culture of the org and so on. But in a lot of cases architectural flaws are at the root of it. The real question with a rewrite is a cost-benefit one. And it's based on estimates so there should be a lot of room for error.

quickthrower2 5y ago

A way around this is a side by side test of a lot of the functions. Maybe generate tests form system 1 outputs and use them to test the greenfield system. Where they differ you then decide where the bug is.

adam_arthur 5y ago
Yeah this would work very well for certain types of apps. An API would be easy to validate with this approach, for example.

adam_arthur 5y ago

Yeah, definitely a good rule of thumb :) But in this case a total rewrite would have saved time, and improved velocity. Looking back on it. It was impossible to really know at the time, though. Fortunately this project was more presentational than business logic heavy, so missing functionality would have been easy to notice when testing (all visual). I wouldn't agree that running is a sign of success necessarily. There are a lot of running legacy systems that get beaten out and replaced by competitors due to low development velocity. Of course a lot of that comes down to the culture of the org and so on. But in a lot of cases architectural flaws are at the root of it. The real question with a rewrite is a cost-benefit one. And it's based on estimates so there should be a lot of room for error.