I was involved in a complete project rewrite, it was mostly a success but it took a long, long time. The biggest issue is you have a clean slate but a legacy code base that you still need to support, bug fix and frequently improve. Big time sink right there.
Textmate 2 and why you should never rewrite your code
41–50 of 52 posts
Re: Textmate 2 and why you should never rewrite your code
#42I prefer an alternative interpretation: if rewriting your code is an existential risk, you weren't writing it right in the first place. Startups need to value flexibility. The longer they stay flexible -- even in the presence of growth -- the higher their valuations get. So the conclusion seems inescapable: find ways to make rewrites utterly banal. This may seem hard, but I think it's possible. Part of the answer mig…
Agree. I work for a highly successful startup that has gone through several major rewrites on subcomponents and we're fine. Rewrites are not in and of themselves a universal evil - but writing shitty code is.
Sounds more like a large refactoring than a rewrite. Or at the least you already has a service-oriented architecture with a well-defined interface that allowed the rewrite to be sane.
My rule of thumb has always been to break things down into the smallest discrete tasks possible. If you stay on top of your architecture this almost never turns into a total rewrite, but sometimes there is no choice but to get your hands really dirty in a major refactoring. In these cases it's critical that each escalation is well-justified and not just trying to capture more "low-hanging fruit" that the dev team is brainstorming in high-level discussions.
Re: Textmate 2 and why you should never rewrite your code
#43Are there really no instances of rewrites succeeding? Are we sure that projects that failed doing rewrites wouldn't have failed more painfully if they'd continued dealing with the cruft of the old codebase? It's possible the problem is more in how these projects went about their rewrites, than just the fact that they did. What was the scope of the rewrite - did they simultaneously re-architect, redesign the UI, and t…
It depends on the individual case. It's not always possible to isolate subsystems in order to refactor incrementally, but on the other hand it's also almost certainly a foregone conclusion that you will underestimate the complexity of a rewrite.
Re: Textmate 2 and why you should never rewrite your code
#44And yet Firefox rose from the ashes of Netscape. Who would have thought Mozilla would become relevant again five years after Netscape died? I'm starting to think open source projects are a lot more hardy than startups because they can't run out of money.
It's possible that Firefox would be more mature or popular than it already is if they never did the rewrite.
Doubtful. The old rendering engine was a dead end and everyone knew it. Netscape 5 still would have been miles behind IE 6, and it would have taken substantial engineering effort to get it there. Instead, they focused on Gecko and Mozilla.
Re: Textmate 2 and why you should never rewrite your code
#45And yet Firefox rose from the ashes of Netscape. Who would have thought Mozilla would become relevant again five years after Netscape died? I'm starting to think open source projects are a lot more hardy than startups because they can't run out of money.
It's possible that Firefox would be more mature or popular than it already is if they never did the rewrite.
1. There's no way to confirm or falsify that counterfactual.
2. Even if we stipulate that Firefox would be more mature/popular without the rewrite, I think there are many decisions that might have had an equal or larger impact. For example, the design choices they made for their plugin architecture made it harder to compete when Chrome came along, and have had deep influence on their ability to do frequent unobtrusive releases. If you admit one counterfactual you must admit them all. Was the rewrite really the biggest turning point in their trajectory?
3. If you'd offered the firefox creators the level of success it has today, they would take it in a heartbeat. Quibbling about levels of success is a luxury you can only afford after you have managed to not die. (http://paulgraham.com/die.html) That was what my comment was concerned with.
Conventional wisdom (http://www.joelonsoftware.com/articles/fog0000000069.html) makes the far stronger claim that rewrites kill; if we retreat to arguing levels of success I will happily declare victory and go home :)
Re: Textmate 2 and why you should never rewrite your code
#46Earlier quoted context omitted.
In other words, this is a prototypical HN submission. Progblogging is so bad.
I've submitted like 3 articles to hacker news, I'm clearly not a pro.
I think mattacular wrote about the run-of-the-mill programming blog that gets submitted to HN. They feel more substantial than one of those spammy "125 free icon sets that'll turn you into a Design god", but they're mostly half-baked regurgitations of Software Engineering folk-wisdom, rehashed from a dozen other blogs which quote some testimony from a famous book.
No code, no maths, no algorithms, no statistics, no nothing.
Re: Textmate 2 and why you should never rewrite your code
#47Earlier quoted context omitted.
Do you have any examples of Microsoft throwing away their codebase and starting fresh? I believe that is what Apple did with the OS9 to OSX transition. I can't think of too many examples where starting from scratch worked out though.
But Apple didn't really "start fresh" internally with OSX, they acquired NeXT which was already a pretty robust product when they made that decision. The abandoned the OS9 codebase, but they didn't really start over from a blank slate.
Well there was also the many-years development of Copland that ultimately failed and precipitated the purchase of NeXT just to get a decent OS.
It's hard to say whether Copland was a rewrite or a refactoring, but what is indisputable is that the root architectural decisions of Mac OS were a dead-end.
They actually had to go beyond a rewrite to build something completely new and different, and then retrofit an emulator onto it to support the old system.
Re: Textmate 2 and why you should never rewrite your code
#48The Netscape rewrite became Firefox.
Which still killed the Netscape brand and the sluggishness of that rewrite contributed to IE becoming dominant.
Yes but who are we to say that the Netscape 4 codebase was refactorable? Maybe they would have lost momentum and simply died with nothing to show for it at all.
Re: Textmate 2 and why you should never rewrite your code
#49Are there really no instances of rewrites succeeding? Are we sure that projects that failed doing rewrites wouldn't have failed more painfully if they'd continued dealing with the cruft of the old codebase? It's possible the problem is more in how these projects went about their rewrites, than just the fact that they did. What was the scope of the rewrite - did they simultaneously re-architect, redesign the UI, and t…
> Are there really no instances of rewrites succeeding?
The most famous instance of a successful rewrite was IBM's transition to OS/360 [1] in the 1960s, which was not just a complete rewrite but a completely new system to replace all the previous ones. (The "360" comes from the number of degrees in a full turn.)
Who spearheaded this huge effort? A certain Frederick P. Brooks, who used his experience with the project to write _The Mythical Man Month_, which coined the term "second-system effect" [3].
Of course, while the 360 project was _ultimately_ successful, they made all the now-familiar mistakes that Brooks documented in his book -- it was an extremely expensive and time-consuming project that was only possible thanks to IBM's enormous resources and strong leadership.
---
[1] http://www-01.ibm.com/software/os/systemz/pdf/360Revolution_...
Re: Textmate 2 and why you should never rewrite your code
#50> Look at it as a living organism that can perhaps be healed, and can evolve.
What life we can see now is only survivors and most of gene line actually failed.