3 ms·
I 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
by akkartik 14y ago
I 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 might be replacing compatibility concerns with automated tests to a far more comprehensive level: http://news.ycombinator.com/item?id=4361596 http://news.ycombinator.com/item?id=4361596.
One benefit of Google's NIH syndrome that I think people don't focus on enough: because they built the entire stack from scratch they had no backwards compatibility overheads in the early days. (Of course this is no longer true.)
- zenogais 14y agoAgree. 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.
- dasil003 14y agoSounds 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.