每一个软件项目的第一个版本都很漂亮。新项目从零开始，所有的内容都是新开发的。因为全新开发，就意味着没有历史负担的问题。第一个版本的BUG非常少，当然，程序员也尽力做到最好。这意味着，在开发人员的眼中，第一个版本可以算是完美：代码漂亮、设计良好、架构优秀。
第一个版本一旦发布，就会有人发现BUG，并公布出来，这些BUG都需要被修复。这时，第二个版本的起点就要比第一个版本高得多。第二个版本并非从零开始，而是建立在所有问题的基础上。而且，对于大部分的软件项目来说，往往没有足够的资源和时间把事情做得非常完美。所以对新版本的调整和修改就没有第一个版本那样漂亮和整洁。
这样就会在后续版本中不断地增加软件熵，代码变得越来越难以维护。负责维护的开发人员开始天天抱怨，特别是那些代码原作者已经联系不上的情况下，抱怨就更加严重。
终于有一天，项目会处于一个特定的阶段，此时，开发人员只能说：“别去动这个软件了！”。代码犹如一团乱麻，任何改变都有可能让某些功能无法正常运行。问题越来越大，最后管理层得到的信息就是这个软件病入膏肓了，他们也许会决定重新开发一个软件。
很有可能，开发新的版本所用时间会比原计划的时间要多得多。而且功能也可能比老版本还要少。但这个新版本将会非常漂亮和整洁。很明显，因为这个版本又是从零开始了。从设计角度来说，不会有什么问题。这个版本又像第一个版本一样的优雅、漂亮。现在终于达成我们预计的目标了。
事实上，出现在第一个版本中的问题也会同样出现在最新重写的这个版本中，代码会再一次地变成一团乱麻，需要有人去维护，会引入各种修改方法，所有出现在第一个版本中的问题都会一一重现。直到有人痛下决心，想从根本上解决问题时，又会出现前面的那种推倒重写的事情。虽然重新开发新的版本的确付出了不少努力，但每一次我们都会重新回到起点，重犯之前的错误。这种努力就是白费。
对于推倒重来的这种做法，我们往往是抱着会有更好结果的想法去为之，但最终却往往是同样的错误一犯再犯。所以没有任何理由支持我们这样从头开始来做一件事。如果想要一个更好的结果，就需要改变开发的方式。只有改变了开发方式，才可能有更好的结果。
总而言之，要学会使用增量迭代、小步前进的敏捷开发方法！人们需要软件加以改进，但改进时引入的伤害也应该最小化，特别是要避免只为增加功能而不顾设计走捷径使用非正常手段的情况。
参考书籍：
英文原名：Practical API Design: Confessions of a Java Framework Architect
中文译名：软件框架设计的艺术