程序员和产品经理几乎每天都在和各种各样的Bug打交道。当一个特性以代码的形式进入产品的时候，就伴随着各种各样的Bug，直到发布之前，都会一直处于发现Bug，修复Bug的循环中。
出现了Bug就要修复，这似乎是再自然不过的事情，但是有时产品经理发现Bug之后，兴冲冲地去找程序员修复时，得到的答复却是——“这个Bug我知道，原因很清楚，但就是不能修复”。
首先，上线在即，修复Bug会产生不确定的后果。这种情况比较常见，也是产品经理和程序员都认同的。
很多时候，不同程序员之间的代码是纠缠在一起的，虽然从产品的角度看，修复一个Bug只是修复一个局部的小问题，但在测试不够充分的情况下，程序员自己都没有信心保证这个修改会不会对其他地方造成影响。
这是无数次“血的教训”换来的谨慎。
其次，这个小Bug可能是被设计出来以隐藏一个更大的Bug。
有时，产品经理觉得程序员做出来的产品和最初设计的存在偏差就算是Bug，但开发人员知道产品与设计有出入，是为了避开某些“坑”（有可能是系统的，也可能会是别人的），不得已才进行了调整，以避免引发更大的问题。
他们的具体操作可能是用一点颜色上的偏差来解决系统潜在的绘制问题，又或是按照正常的实现方式会触发一个别的操作路径上的程序崩溃，于是添加很多额外的条件让它成为一个小场景下随机出现的问题。
最后来说说不能修改的Bug中的“极品”。
一个产品的开发过程往往不是直线形的，有的甚至变更得非常频繁。
而在写代码这个问题上，每个开发人员都有自己独特的思想，脑海里有各种设计和架构，现实中，他们在遇到各种难以解决的问题后学会了各种新奇的技巧，它们在程序代码中的体现令接替的人几乎难以理解其中奥妙。
为了保险起见，在遇到新问题时，后者往往不愿意调整旧的逻辑，而是施展自己的技巧解决各种古怪的问题，如此反复，最后的代码已经到了只能看不能动，但程序又能基本正常运行的神奇境界。
产品体验员感觉到的可能只是些小问题，比如某些Bug看似换张图就能解决，却被告知不能修复。
有些开发者敏锐度很高，在感觉“填坑”力不从心之时选择离开，在代码注释留下一句“祝你好运”来勉励接手的人。
很多产品中或多或少都存在这些问题，正常情况下当然是不鼓励这样做的，不过在程序员时不时离职脱坑的情况下，程序员也顾不了那么多。
