之所以存在软件噩梦，是因为软件需要改进和维护，这是软件生命周期的一部分，正如人类的生老病死一样，即使你不喜欢，但是他依然会来临，它不会因为你不喜欢或者抗拒而不来。你所能做的，正如当下流行的一种说法，如果你无法反抗，就学会享受。
这正如我在团队中所倡导的一样，很多问题，之所以不能解决或者是不能很好的解决，是因为从一开始我们就没有承认这个问题。那么解决问题的第一步就是先承认问题的存在，存在即合理虽然大家都会说，但是很少有人会仔细的去思考，尤其是在工程项目之中。我常常听到的一句话就是“这不可能”。还有往往也有那样的抱怨“用户老变”，“这是人的问题”等等这些抱怨，这些抱怨的背后都存在一个问题，即问题解决者对于问题的否定，也就是说他们承认了一部分问题而对另一部分问题的不承认。比如“用户老变”这种抱怨，首先最严重的问题在于，他们从来不承认用户变化这种情况，所以不能很好的去追求问题本源，不能去提前制定预案，所以当问题出现的时候，就会出现那种抱怨。
还有一种非常常见的情况就是“这是人的问题”的这种抱怨。尤其是当问题出现的时候，开发人员通常会说这是用户操作的问题。当开发人员因为粗心而调用API错误的时候，这时候大家也都会觉得是调用者的问题（其实很多时候是API开发者没有做好接口的“用户交互”），尤其是很多技术人员这样去思考。这种普遍的情况使得技术和人被本末倒置了。这种情况我遇到最多的有两处，一处是用户界面，一处是接口调用,也就是前面所举的两个例子。
改进评价
既然软件存在问题，那么如何面对这种问题？是面对还是逃避。有时候你可以逃避，但更多的时候你必须去面对他。这又得重申一下我的理念了，对于任何问题，你只有承认它的存在，才能解决它。
既然软件存在问题了，那么做改进还是不改进，你肯定会说，必须做改进啊。错了，在真正的遇到的问题的时候，很多人不做改进。一般情况下当事人会觉得改进的影响和成本都高于修修补补。所以问题就这样被不断的放纵下去，终有一天无法修补了或者运气好点没有到这一天软件就已经废弃了。当然了，也不是说遇到问题了二话不说就去做改进，这种做法也不提倡。
对于是否要做大的改进，应该从几个方面来判断。
1、 是否和设计相关，如果出现问题了，发现修补不能从根本上解决问题，那么看看是不是设计方面的问题，如果是设计上面的问题，那么就需要考虑去改进。采用鸵鸟算法(参考文献[19])来逃避只会给以后带来更大的麻烦。
2、 是否是核心，发现的问题是核心方面的问题，这个核心方面不管是业务还是技术，如果这块存在问题，那么一定是要改进的，因为核心是一直存在的，一时的搪塞只不过是给自己埋地雷而已。
3、 是否是以后扩展的瓶颈，这个很明显，如果问题处于敏感地带，有非常大的可能性是以后扩展的阻碍，那么就毫不犹豫的去改进和重构。当然了是不是以后扩展的瓶颈这个不是很容易能看出来，对系统熟悉或者有了一定经验之后还是不难看出来的。重要的地方在于要有这个意识，这样不久之后就有这个能力了。
4、 是否有敢于承担改进的人，这一条看似废话的标准其实不是废话，真正在考虑是重构还是修补一下就完事的时候，往往会有各种利益方和不同人员之间的pk和协调，毕竟人都有自己的想法，有想混到下班完事的，有技术狂热到不考虑产品利益后果的，所以是否需要改进还得有一个冷静并且勇于拍板的人。