And I'm sure Netscape is far from alone in that category ;-)
But (disclaimer) as someone who as advocated for big-bang-rewrite's before, I'm still under the impression that there are situations where they can be net-better.
Factors may include:
- there is no database involved, just code. Even more helpful if the existing code is "pure".
- a single developer can hold the functionality in their head.
- there are few bugs-as-features, tricky edge cases that must be backwards-compatibility, etc.
- as stated above, it's the primary author.
- much of the existing functionality is poor, and the path for building, launching, and shifting to a "replacement product" is relatively clear.
Advocating to never rewrite can be harmful, and make things harder for people for whom that actually would be the best approach.
Yes, but those are special cases. For every rule there is an exception, and of course if the parts above apply you are fully in control and are well able to judge whether you should rewrite or not.
But the situation that I'm describing is not ticking any of those boxes and I think I made that quite clear in the pre-amble.
One thing that bothers me is that people tend to expect miracles. I usually tell them it will take as long as it took to fuck it up to fix it. But that doesn't mean that you can't have some initial results to point the way in a short time. It's more about establishing a process and showing that there is a way out of the swamp than that it is something super tricky or difficult. Just follow the recipe, don't let yourself be distracted (this can be really hard, some management just can't seem to get out of the way) and keep moving.
But (disclaimer) as someone who as advocated for big-bang-rewrite's before, I'm still under the impression that there are situations where they can be net-better.
Factors may include:
- there is no database involved, just code. Even more helpful if the existing code is "pure".
- a single developer can hold the functionality in their head.
- there are few bugs-as-features, tricky edge cases that must be backwards-compatibility, etc.
- as stated above, it's the primary author.
- much of the existing functionality is poor, and the path for building, launching, and shifting to a "replacement product" is relatively clear.
Advocating to never rewrite can be harmful, and make things harder for people for whom that actually would be the best approach.