How to Avoid One of the Costliest Mistakes in Software Engineering

http://www.theeffectiveengineer.com/blog/cardinal-sin-of-software-engineering

One of the worst parts about long rewrites is that when a critical new market opportunity comes up that requires building on top of the code being rewritten, you have to make a difficult choice: do you defer (and possibly lose) the opportunity by building on top of the new codebase and waiting for the new codebase to ship, or do you build it on top of the old codebase and then rewrite it a second time in the new? Neither choice is that appealing.（长时间重写中最糟糕的一件事情便是，一个紧急的新市场需求来了需要马上实现。这个时候你有两个选择：1. 延迟这个需求知道新的codebase完成 2. 在老的codebase上实现需求然后再次重写。两个选择都不是好主意）

The rewrite projects I worked on were painful but formative experiences. Since then, I’ve learned to be extremely wary any time someone proposes an ambitious rewrite project. I’m not the only one to feel this way.（所以一旦有人提出要重写项目，对此要格外谨慎和小心）

#Google Docs前身是Writely，是用C#编写的。被Google收购之后要求迁移到Java平台。一开始他们只是想做translating, 但是一个co-founder要求重写部分codebase. 所以有工程师索性就打算重现整个代码。幸好这哥们发现早及时制止了，只让重写有限的codebase其他都是translating. 即便如此还是花费了12周才完全搞定。

The message isn’t that we shouldn’t ever rewrite or throw away code. We’re always developing software with imperfect information about how it’s going to be used or what the eventual requirements might be. Eliot Horowitz, the founder of MongoDB, remarked once at conference that you should think of code as having a half-life of 3-5 years, and therefore needs to be refreshed periodically. Jeff Dean, the architect behind Google technologies like MapReduce, Bigtable, and many more, said to design your software to scale by 10x, after which the best design will likely look quite different.（代码是有生命周期的，按照EH的看法是3-5年就是半衰期，而JD也曾说过只需要为10x scale问题设计。所以代码重写是一件非常正常的事情）

The problem surfaces when we rewrite entire codebases from scratch and in one go. We tend to significantly underestimate the cost and overestimate the benefit.（我们严重低估了代价而高估了收益）

When we’re inexperienced, we underestimate because we have little idea of how long things will take. We don’t have enough clout or knowledge to say no to aggressive schedules. We lack the prioritization and technical skills to effectively reduce variance in the timelines. We think to ourselves, A good engineering team would be able to do this. We just have to work hard enough and demonstrate that we’re good.（当我们缺乏经验时，我们低估是因为我们不知道如何评估一件事情花费多久，也没有足够的经验和影响力来对agressive schedulers说No, 缺乏优先级管理和手段来减少timeline上的偏差，总是想急于证明自己）

And when we’re experienced, we underestimate partly because estimation is still hard and partly because we’re overconfident about our abilities. It’s a case of illusory superiority. Ask 100 drivers about their driving abilities, and 80% will rate themselves as above average. Ask 100 teaching faculty, and 68% will rate themselves in the top 25% for teaching ability. The same lopsidedness shows up in estimation of IQ, test scores, memory, job performance, and more. So it’s no wonder that many software engineers believe that deadline slips only happen to average or below average teams and that they themselves are insusceptible to the types of deadline slips that have plagued software rewrites for decades.（当我们有经验时，我们低估部分上是因为我们对于自己能力过于自信。许多软件开发人员总是认为其他团队不能在deadline之前完成是因为说明太low，而事实上因为软件重新而项目延期的事情数不胜数）

When deadlines for rewrites do slip, we often delude ourselves with optimistic beliefs that maybe we’ll just work harder and find ways to make up for lost time. We convince ourselves that there’s no other alternative. It might work once or twice, but as a long-term strategy, it’s not sustainable. You can’t sprint to the end of a marathon. （当快临近dealine时，我们经常带着乐观的信念欺骗自己只要加班就搞定，初次之外别无他法。这样可以成功一两次，但是作为一个长久策略这是不可持续的，就像没有人会用冲刺跑来跑马拉松）

The best strategy then is to be skeptical of the value of rewriting entire codebases from scratch. When you do have to do it, like Schillace did, you tackle it with a limited set of goals to get as quickly as possible to a state where you’re again making incremental improvements. And if you do find yourself joining the ranks of other software engineers who fell prey to a slipping rewrite project, you need to have an honest but difficult conversation on how to bridge the gap between your desired business target and your underestimate — whether it’s by cutting features, resetting the project to a more realistic timeline, or treating the project as a sunk cost and abandoning it all together. Tactics exist for each of these, but none are as impactful as how you initially frame the rewrite project.（最好的策略就是对重写codebase保持怀疑态度。如果一定要做的话，就要像schillace一样设定特定目标然后快速完成，之后再这个基础上做增量改进。如果你加入了一个团队，内部成员都想重写，那么必须想出各种办法来让项目对接上）