在「敏捷开发经典」中读到了一个有趣的故事，让我陷入了沉思。虽然 | SheronW in the box

在「敏捷开发经典」中读到了一个有趣的故事，让我陷入了沉思。虽然有中文译本，但这里放一下自己拙劣的翻译：

如果我们只是需要打造一个生命周期非常短的产品的话，考虑到经济因素，技术负债（Technical Debt）可能不应该被还清。一个我在80年代末遇到的有趣例子可以用来描述这种类型的场景。那时我为 ParcPlace System （一个OOD环境的早期市场领头羊）工作，并帮几个高调的华尔街投行采用 Smalltalk 作为开发环境。有次我被带去帮助一个团队更好地理解面向对象并更高效地使用 Smalltalk 开发环境，他们刚刚搞了一个业内首创的衍生品交易系统。我开始审查这个产品的设计和实现，不过这个产品不久之后就要上线了。

审查了几天架构和代码，我与 VP 见面，告诉他这系统是我见过的最烂的 Smalltalk 实现。我还指出项目中有无数的问题，如果不立刻解决，会对系统（甚至业务）造成严重后果。

那个时候 VP 一字一句地和我说：「年轻人，如果你敢花5美分去收拾这个系统，我会亲自把你带出去一枪毙了。」我可以说被他的评论搞得一脸懵逼，就回复道：「你要在这一点上相信我，这个系统设计不足并且实现差劲，你的产品会在长期有很大问题。」他反驳说：「你不懂我的生意——在这个市场，每推一个新的金融工具，我的绝大部分利润都是在前三个月里赚到的。在那之后，我的竞争对手就会带着竞品冲进来，所以我最好的选择是退出这个市场然后创造一个新的产品。我只需要这个新系统存活三个月。我根本不 care 你是用口香糖还是捆绑钢丝把零部件拼起来的，只要不耽误我创造营收、给我的竞争对手创造打败我的机会就行了。我们会就这样交付这个产品。」

然后他们就这么做了。该产品上线后仅仅几个小时，交易员就用它创造了1400万美元的营收。我个人认为他们在系统脆弱的情况下就将产品上线是一种冒巨大风险的行为，但在创造营收方面，我可能错了。