4 ms·

tl;dr : Re-writes are usually a disaster - be absolutely certain of your ground before undertaking one. ======== The major question to ask is "why?" - and ask

tl;dr : Re-writes are usually a disaster - be absolutely certain of your ground before undertaking one. ======== The major question to ask is "why?" - and ask it repeatedly. * Why is it a mess? * Why do you think writing it from scratch will be faster than fixing it? * Why do you think you can spend the time creating nothing new for X weeks while you re-write? * Why do you think you will produce something better/smaller/faster/cleaner/less buggy? Here are some thoughts: * Maybe it's a mess because the original design was fundamentally wrong and it really can't be guided into the right form. * Maybe it's a mess because people kept adding features without really understanding how it worked, so their additions didn't fit the architecture/design/structure. But maybe it's a mess because it's doing stuff you don't yet recognize as being important, so what's there is essential complexity. Some anecdotes and background. I've overseen two complete re-writes, and five on-going re-workings. One re-write was a success both technically and commercially, the other was a near complete disaster. Four of the re-workings are still underway and the product has remained live, sellable and profitable the whole time. The fifth is under constant review, but is not a disaster. So re-writes can work, but the experience is that they usually don't. Go against the advice only if you are certain of your facts.

sankara 16y ago
>>* Maybe it's a mess because the original design was fundamentally wrong and it really can't be guided into the right form. >> >>* Maybe it's a mess because people kept adding features without really understanding how it worked, so their additions didn't fit the architecture/design/structure. I'm not looking to blame anyone. Whatever has happened, has happened already (I'm not ignoring the learnings) and I'm just looking to improve things.
- RiderOfGiraffes 16y ago
  Blame is not the point. Assume that the original authors aren't stupid. Maybe they were, but assume they weren't. Now ask - how did this get in such a mess? Why did this get in such a mess? How do I know that if I rewrite it I won't make the same mess? If you can't answer that then you can't decide whether to re-write or refactor. Knowing why it got in a mess is a crucial piece of information. Are you cleverer than the original authors? Do you know more than them about the problem? Remember, they spent ages writing that code - they know lots about the problem. Are you sure you understand it better? Unless you can answer absolutely, unequivocally yes then you shouldn't rewrite. You should work to improve the existing code in small pieces. Only when you believe you understand it better than the original authors should you make the decision to rewrite. Otherwise you are mostly likely to spend a lot of time recreating their mistakes.
  - sankara 16y ago
    I'm sorry if I misread. It is a combination of two. As I had mentioned in a previous comment everything from process to environment to developers has changed for the better. Thank you all for your valuable suggestions.

sankara 16y ago

>>* Maybe it's a mess because the original design was fundamentally wrong and it really can't be guided into the right form. >> >>* Maybe it's a mess because people kept adding features without really understanding how it worked, so their additions didn't fit the architecture/design/structure. I'm not looking to blame anyone. Whatever has happened, has happened already (I'm not ignoring the learnings) and I'm just looking to improve things.

RiderOfGiraffes 16y ago
Blame is not the point. Assume that the original authors aren't stupid. Maybe they were, but assume they weren't. Now ask - how did this get in such a mess? Why did this get in such a mess? How do I know that if I rewrite it I won't make the same mess? If you can't answer that then you can't decide whether to re-write or refactor. Knowing why it got in a mess is a crucial piece of information. Are you cleverer than the original authors? Do you know more than them about the problem? Remember, they spent ages writing that code - they know lots about the problem. Are you sure you understand it better? Unless you can answer absolutely, unequivocally yes then you shouldn't rewrite. You should work to improve the existing code in small pieces. Only when you believe you understand it better than the original authors should you make the decision to rewrite. Otherwise you are mostly likely to spend a lot of time recreating their mistakes.
- sankara 16y ago
  I'm sorry if I misread. It is a combination of two. As I had mentioned in a previous comment everything from process to environment to developers has changed for the better. Thank you all for your valuable suggestions.