有些时候，无需偿还技术债。这也是源自于财务债的类比。通常来说，那就是所有财务债最终都会被偿还，尽管我们都知道，实际上并非一直如此！
有些情况是无需偿还技术债的。我将介绍其中三种：行将就木的产品、一次性原型和短命产品。
行将就木的产品
如果产品已经积累大量技术债且已临近生命周期的终点，再投入大量精力偿还技术债就是财务不尽责了。如果产品价值不高，就让产品退市（跟债务一起），将资源投到价值更高的产品。对于是高价值、高技术债的产品，与其偿还它欠下的技术债，还不如承担高风险以高成本开发新产品，这样做更有意义。
一次性原型
有时，我们会有意负担技术债却根本不想还，这样做反而是最经济合理的。常见的一个例子是为获取知识而创建一次性原型（Goldberg and Robin 1995）。原型的价值不至于代码，而是我们得到的经验认知（Ries 2011）。原型不是为了市场而设计的，所以可能会欠下一些甚至大量技术债。然而，既然是一次性原型，我们也没必要偿还他欠下的债务。当然，如果在做出一次性原型之后又决定留下它作为一个可演变为产品的演进原型，就肯定得先收拾这个技术债高筑的烂摊子。
短命产品
如果是构建一个短生命期的产品，经济因素可能支持不偿还技术债。我用一个有趣的例子来说明，事情发生在20世纪80年代后期。当时，我就职于ParcPlace System 公司，面向对象开发环境的早期市场领跑者。那时，我是在帮助华尔街的几家知名银行采纳Smalltalk 作为开发平台。有一次情况比较特殊，他们要求我指导某个团队，帮助成员更好地理解面向对象技术并更有效地使用Smalltalk 开发环境。该团队刚刚做完一个开创性的金融衍生交易系统。抵达现场后，我先向该集团副总裁提出检查一下团队这个新建产品的设计和实现，当时该产品还没有上线，不过已如箭在弦，很快就要上线了。
经过一整天的架构和代码检查，我和副总裁碰面，告诉他这个系统可能是我所见到的最难看的Smalltalk实现。我指出它的问题多得数不清，必须马上处理，否则系统（以及业务）会让大家进入悲惨世界。
当其时，这位副总裁告诉我（一字一句地）：“孩子，哪怕你花我一个子儿去清理系统，我也会亲自把你逮出来毙掉。”可能是被他的言辞给吓到了，我解释道：“这事儿你得信我。系统的设计很差劲，实现很糟糕，有根本性的问题。”他反驳道：“你不懂我们这一行。在这个市场里，如果我们推出一套新的金融工具，就能在前三个月内迅速攻城略地，占据大部分市场份额。三个月，竞争对手得需要这么长时间才能突击完成跟风产品并投向市场。等到那时，我往往已经离开市场转而去开发另一套新产品了。我的想法是，新系统能够坚持三个月就行。我不关心你是不是要用口香糖和钢索搞定这个系统。我只希望不要耽误我创造利润，不让竞争对手有任何机会在市场上打败我。这个系统必须马上上线。”
他们果然说一不二。系统上线的第一个小时，交易员就用它创造了1400万美元的利润。从我个人角度来看，上线一个脆弱的系统对他们来说存在巨大的风险，但从利润的角度看，我的想法显然错了。
组织通常不会做预期只有三个月生命的产品。一般情况下，我们更愿意开发能够长销的产品。
作者：Kenneth S. Rubin
译者：知名敏捷教练 姜信宝 Bob Jiang
转载自：《Scrum精髓》
