[转]企业自杀行为：重写程序Startup Suicide – Rewriting the Code

本文是从 Startup Suicide – Rewriting the Code 这篇文章翻译而来。

敏捷开发和最小化功能组合的好处是能持续得到客户反馈，快速迭代，防止无用程序的产生。但是随着时间的推移，如果开发人员不注意，那些为早期客户编写的程序会变得笨拙不堪，难以维护，无法扩展。你最终会讽刺的得到和敏捷方法完全相反的结果。而且问题的严重程度会随着公司的壮大呈指数级增长。合理的解决方案是什么？把产品“重构重写”。

对于处于快速变换的市场中的一个公司，这通常是走向灭亡的开始。

看似很合理

我刚好和一位朋友在加州的Palo Alto共进午餐，他是一个科技公司的创始人，现在出任董事会主席。几年前他聘请了一位职业经理做CEO。我询问他工作做的如何(“非常好，谢谢你的关心，五年来，公司现在的市值已经达到5千万美元”)，但他却想跟我谈一个在他脑子里想了很久的问题。“随着公司的壮大成长，我们对市场变化和客户反馈的反应越来越迟钝。虽然现在我们的营业收入看起来还不错，但如果我们不能使公司的产品平台跟上客户需求的快速变化，一两年内我们就可能完蛋。我们的CEO没有技术背景，但他也为公司不能开发出他想要的一些新功能和平台(Facebook,iPhone,Android等)而沮丧。在最近的一次董事会会议上，我们主管技术的副总裁指出问题的根源在于‘我们的程序积累了太多的技术债务‘，程序实在是糟透了，我们现在根本没法处理。他告诉董事会，如果想在其上做我们想要的修改，那只能重写这个产品。”我的朋友补充道，“这听起来很合理，所以CEO打算批准这个计划。”

举枪自杀

“那么董事会在听到这种鲁莽的计划后没有做任何反应吗？”我问道。“没有，”朋友回答道，忧郁的摇摇脑袋，“董事会成员都感觉这像个好主意。”

经过更详细的询问后，我了解到他们的已经膨胀巨大的代码库中还保留着公司早期在拓荒阶段为客户开发的代码遗迹。当初针对客户的产品技术设计对于公司当前所面对的新平台的扩展任务来说并不是正确的设计。

我提醒我的这位朋友，我从来没有做过技术管理，所以任何我给他的建议都是来自于经历过这种事情的他人。

引诱非技术出身的CEO的美妙海妖歌声

CEO在其职业生涯中至少会遇到一次这样的“重写”问题。如果他是被请来替代技术创始CEO的，那这个决策似乎很好定——只需要对比一下负责技术的副总裁提供的重写(短期)进度计划和保留老代码、增加新功能(长期)的进度计划就行了。而事实上，这是个愚蠢的决定。技术团队也许会知道使用旧程序的困难和问题所在，但不会知道如果重写代码库将会面对多少的困难和问题。

曾经经历过重写噩梦或理解程序的复杂性的CEO会知道，没有最初的技术开发团队，重犯以前曾经犯过的错误的几率会非常的高。加之会引入以前不曾犯过的错误，根据墨菲法则，不受约束的乐观主义会使1年期的重写计划变成数年。

我的观点是，CEO和主管技术的副总裁混淆了因果。客户并不要求新的程序。他们要的是新的功能和平台—— 在当前。他们不太关心这些功能是由一堆糊涂代码、还是由外星飞船、还是由一个新产品提供的。当你在代码重写的过程中，那些不痴迷于架构血统纯度的竞争对手会扩展他们的功能、平台，拉拢客户、增加市场份额。这种目前就增加这些功能、还是一两年后再增加这些功能之间的区别代表着收入增长、还是被淘汰出局两种境况之间的区别。

谁想要老的产品

也许这着手搞程序重写最危险的副作用就是当你对旧的程序宣告死亡时却没有可替代的产品存在。当副总裁和CEO宣告公司将来要采用新的程序时，谁还会去重视这充满问题的旧程序呢？当管理者说出“重写”这个词时，老的程序就死掉了。这后果就是，CEO没有退路可走。如果技术副总裁的开发进程最终是花了4年时间，而不是设想的1年，那么在这几年期间对于系统新功能的增加不会有任何的进展。

这是一种预测的失败

我认为这看起来像是技术副总裁蓝景设计上的失败——再加之没有代码重写经历的CEO推波助澜——再经过想不出具有建设性的方案的董事会们的搅和。

给朋友的建议？指出市场的快速变化和竞争性，指出这种动作会使公司致命。公司在前进道路上的探索不应该在时间对于市场至关重要的情况下、在客户的需求快速转换的情况下对代码库进行重写。重写是在竞争周期比较长的市场条件下才可行。

我建议他应该在董事会会议上把这些情况陈列清楚。要求CEO详细列出什么时候需要什么样的功能和平台特征，用什么样的手段对进度计划管理的风险进行控制。弄清楚这种完全不同的技术方案是否真的可行。(是否可以只重构目前需要追加新功能的部分模块？在新的代码库上开发要求的新平台系统？启动一个独立的分支工作团队来开发新平台？等等)

转自：http://kb.cnblogs.com/page/90988/

英文原文：http://steveblank.com/2011/01/25/startup-suicide-%E2%80%93-rewriting-the-code/

Startup Suicide – Rewriting the Code

Posted on January 25, 2011 by steveblank

The benefits of customer and agile development and minimum features set are continuous customer feedback, rapid iteration and little wasted code. But over time if developers aren’t careful, code written to find early customers can become unwieldy, difficult to maintain and incapable of scaling. Ironically it becomes the antithesis of agile. And the magnitude of the problem increases exponentially with the success of the company. The logical solution? “Re-architect and re-write” the product.

For a company in a rapidly changing market, that’s usually the beginning of the end.

It Seems Logical
I just had lunch (at my favorite Greek restaurant in Palo Alto forgetting it looked like a VC meetup) with a friend who was technical founder of his company and is now its chairman. He hired an operating exec as the CEO a few years ago. We caught up on how the company was doing (“very well, thank you, after five years, the company is now at a $50M run rate,”) but he wanted to talk about a problem that was on his mind. “As we’ve grown we’ve become less and less responsive to changing market and customer needs. While our revenue is looking good, we can be out of business in two years if we can’t keep up with our customer’s rapid shifts in platforms. Our CEO doesn’t have a technology background, but he’s frustrated he can’t get the new features and platforms he wants (Facebook, iPhone and Android, etc.) At the last board meeting our VP of engineering explained that the root of our problems was ‘our code has accumulated a ton of “technical debt,’ it’s really ugly code, and it’s not the way we would have done it today. He told the board that the only way to to deliver these changes is to re-write our product.” My friend added, “It sounds logical to the CEO so he’s about to approve the project.”

Shooting Yourself in the Head
“Well didn’t the board read him the riot act when they heard this?” I asked. “No,” my friend replied, sadly shaking his head, “the rest of the board said it sounded like a good idea.”

With a few more questions I learned that the code base, which had now grown large, still had vestiges of the original exploratory code written back in the early days when the company was in the discovery phase of Customer Development. Engineering designs made back then with the aim of figuring out the product were not the right designs for the company’s current task of expanding to new platforms.

I reminded my friend that I’ve never been an engineering manager so any advice I could give him was just from someone who had seen the movie before.

The Siren Song to CEO’s Who Aren’t Technical
CEO’s face the “rewrite” problem at least once in their tenure. If they’re an operating exec brought in to replace a founding technical CEO, then it looks like an easy decision – just listen to your engineering VP compare the schedule for a rewrite (short) against the schedule of adapting the old code to the new purpose (long.) In reality this is a fools choice. The engineering team may know the difficulty and problems adapting the old code, but has no idea what difficulties and problems it will face writing a new code base.

A CEO who had lived through a debacle of a rewrite or understood the complexity of the code would know that with the original engineering team no longer there, the odds of making the old mistakes over again are high. Add to that introducing new mistakes that weren’t there the first time, Murphy’s law says that unbridled optimism will likely turn the 1-year rewrite into a multi-year project.

My observation was that the CEO and VP of Engineering were confusing cause and effect. The customers aren’t asking for new code. They are asking for new features and platforms –now. Customers couldn’t care less whether it was delivered via spaghetti code, alien spacecraft or a completely new product. While the code rewrite is going on, competitors who aren’t enamored with architectural purity will be adding features, platforms, customers and market share. The difference between being able to add them now versus a year or more in the future might be the difference between growing revenue and going out of business.

Who Wants to Work on The Old Product
Perhaps the most dangerous side-effect of embarking on a code rewrite is that the decision condemns the old code before a viable alternative exists. Who is going to want to work on the old code with all its problems when the VP Engineering and CEO have declared the new code to be the future of the company?  The old code is as good as dead the moment management introduces the word “rewrite.”  As a consequence, the CEO has no fallback. If the VP Engineering’s schedule ends up taking four years instead of one year, there is no way to make incremental progress on the new features during that time.

What we have is a failure of imagination
I suggested that this looked like a failure of imagination in the VP of Engineering  - made worse by a CEO who’s never lived through a code rewrite – and compounded by a board that also doesn’t get it and hasn’t challenged either of them for a creative solution.

My suggestion to my friend? Given how dynamic and competitive the market is, this move is a company-killer. The heuristic should be don’t rewrite the code base in businesses where time to market is critical and customer needs shift rapidly.” Rewrites may make sense in markets where the competitive cycle time is long.

I suggest that he lay down on the tracks in front of this train at the board meeting. Force the CEO to articulate what features and platforms he needs by when, and what measures he has in place to manage schedule risk. Figure out whether a completely different engineering approach was possible. (Refactor only the modules for the features that were needed now? Rewrite the new platforms on a different code-base? Start a separate skunk works team for the new platforms?  etc.)

Lessons Learned

• Not all code rewrites are the same.  When the market is stable and changes are infrequent, you may have time to rewrite.
• When markets/customers/competitors are shifting rapidly, you don’t get to declare a “time-out” because your code is ugly.
• This is when you need to understand 1) what problem are you solving (hint it’s not the code) and 2) how to creatively fix what’s needed.
• Making the wrong choice can crater your company.
• This is worth a brawl at the board meeting.