4 ms·

I've been involved in 3 separate rewrites in different industries, at companies of different sizes, over the course of 20+ years. Not one of them went well. I

I've been involved in 3 separate rewrites in different industries, at companies of different sizes, over the course of 20+ years. Not one of them went well. I've also been involved in maintaining legacy code during that time. The code sucked, and changes were slow, but it went a LOT better than the rewrites did. We actually shipped things.

yibg 7y ago
The problem is it’s not linear. You can ship until you can’t (or can but very very slowly). It’s taking all of the hit now or a little at a time until things completely grind to a haunt. I’ve been involved in a few rewrites as well. Some went well and we had a noticeable productivity gain. Some went badly and we were stuck for a long time fixing bugs and corner cases we had already addressed in the legacy stack. It really depends on the situation.
gchamonlive 7y ago
what motivated those rewrites?
- kstenerud 7y ago
  One was pure vanity. We replaced a perfectly functional codebase in order to support a bunch of new functionality more easily. In the end, what we actually did implement could have easily been done on the old architecture. Another one was a 15 year old codebase. We were also switching to Java. The process had taken 3 years by the time I arrived, and it was eventually canceled. They'd brought in a bunch of consultants (I was one of them), and everyone had their own idea and their own architecture for their parts. The pieces didn't play well together. The 3rd one was just your standard rewrite of a spaghetti codebase. I still think it was the right choice to rewrite, but it took too long and the project was canceled.
  - gchamonlive 7y ago
    I see... Rewrites have to be both justifiable and shouldn't take too long. I am telling that to myself, we have an old code base in php that we would love to rewrite in python, but it must be justifiable. I believe we will do it incrementally, with each new function written in the python framework we have and any code maintenance that won't take too long to rewrite
bborud 7y ago
I have several experiences with both bad and good rewrites. A common pattern among the bad rewrites is that they were too late. Rewrites should be early in a project. Expect to do perhaps 2-3 rewrites at the beginning. Another pattern is that the team was too large. To many chefs and we ended up with an incoherent mess. The good rewrites I’ve done were gradual. We agreed on the target state of the code and on the intermediate stages. Perhaps you could call these “big, slow, refactoring”, but they were in fact rewrites. A couple of rewrites were so successful they changed the rules of the game entirely. People who say rewrites are either all good or all bad are wrong every time.
- goto11 7y ago
  I don't think anybody is opposed to rewriting modules when necessary. The discussion is around "ground up"-rewriting where the whole code base is discarded and starting again from scratch, like how Mozilla did. You can perform a long series of refactoring so you in the end have rewritten everything. The important difference is if you in all the intermediate stages have a working program with all tests passing.
  - bborud 7y ago
    Well, to be fair, the Mozilla rewrite was a combination of runaway ambition/scope, too many cooks and too few of them Michelin class cooks. I wouldn't exactly say that the rewrite itself was the biggest problem they had. When you look up "second system effect" there's a picture of the Mozilla logo. :)

yibg 7y ago

The problem is it’s not linear. You can ship until you can’t (or can but very very slowly). It’s taking all of the hit now or a little at a time until things completely grind to a haunt. I’ve been involved in a few rewrites as well. Some went well and we had a noticeable productivity gain. Some went badly and we were stuck for a long time fixing bugs and corner cases we had already addressed in the legacy stack. It really depends on the situation.

gchamonlive 7y ago

what motivated those rewrites?

kstenerud 7y ago
One was pure vanity. We replaced a perfectly functional codebase in order to support a bunch of new functionality more easily. In the end, what we actually did implement could have easily been done on the old architecture. Another one was a 15 year old codebase. We were also switching to Java. The process had taken 3 years by the time I arrived, and it was eventually canceled. They'd brought in a bunch of consultants (I was one of them), and everyone had their own idea and their own architecture for their parts. The pieces didn't play well together. The 3rd one was just your standard rewrite of a spaghetti codebase. I still think it was the right choice to rewrite, but it took too long and the project was canceled.
- gchamonlive 7y ago
  I see... Rewrites have to be both justifiable and shouldn't take too long. I am telling that to myself, we have an old code base in php that we would love to rewrite in python, but it must be justifiable. I believe we will do it incrementally, with each new function written in the python framework we have and any code maintenance that won't take too long to rewrite

bborud 7y ago

I have several experiences with both bad and good rewrites. A common pattern among the bad rewrites is that they were too late. Rewrites should be early in a project. Expect to do perhaps 2-3 rewrites at the beginning. Another pattern is that the team was too large. To many chefs and we ended up with an incoherent mess. The good rewrites I’ve done were gradual. We agreed on the target state of the code and on the intermediate stages. Perhaps you could call these “big, slow, refactoring”, but they were in fact rewrites. A couple of rewrites were so successful they changed the rules of the game entirely. People who say rewrites are either all good or all bad are wrong every time.

goto11 7y ago
I don't think anybody is opposed to rewriting modules when necessary. The discussion is around "ground up"-rewriting where the whole code base is discarded and starting again from scratch, like how Mozilla did. You can perform a long series of refactoring so you in the end have rewritten everything. The important difference is if you in all the intermediate stages have a working program with all tests passing.
- bborud 7y ago
  Well, to be fair, the Mozilla rewrite was a combination of runaway ambition/scope, too many cooks and too few of them Michelin class cooks. I wouldn't exactly say that the rewrite itself was the biggest problem they had. When you look up "second system effect" there's a picture of the Mozilla logo. :)