4 ms·
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 p
by 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 agoI 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 agoWell, 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. :)