一个函数名引发的悲剧

一个新产品历经3-4年终于推出，出货每季增加，大家皆大欢喜。不想碰上一个Y国的刁钻客户，硬是测出可能若干天中有个短时的迟滞,虽然不影响正常工作。由于该客户过于重要，系统集成厂家以不解决就中断定货威胁，于是从上到下如临大敌,压力全部施加到研发部门。若干年没加班了，被逼到实验室苦战两周白夜。技术这东西，不怕有问题，就怕客户有了问题实验室重复不出来.重复出了问题就算解决一多半了.重复不出天王老子也没办法。不幸这次就是这种情况，只能一招一招的猜想让集成厂商在他们实验室做试验。这系统牵扯了5家公司的技术，期间大家肯定对内先怀疑自己，尽量检查自己的可能问题，这点职业精神应该都有。但对外，都尽量挑对方可能引起问题的各种可能。有时是也许是想借机多刺探出一点对方的东西。有时明知问题不在某处，由于某方的专家质疑，只能无谓的浪费宝贵的时间。

软件工程师检查没问题, 硬件设计也觉得正确. 弄了一周多了没头绪,一天晚上在实验室来回闲走，偶尔听几个工程师议论说一个命令的执行，心中一动：怎么这函数的名字起的这么奇怪。觉得不对劲，追问了几句。一查，原来命令解析有问题！借用以前设计的一个函数但软件是基于这个函数名代表的意义解析实现的,但硬件是根据实际功能要求实现的. 两者有些不一样. 赶紧编译新的命名给客户，果然就是这引起的。

但问题并没完。对方的技术专家们也会战了几昼夜了，一直认为是我们的算法有问题。穷追不舍在控制算法上(也许是想刺探我们的算法吧)。无奈只好写了详细的白皮书解释。为这还咨询了在大学做教授的同学一些理论的东西做弹药。花了同等的精力，把自己觉得不是问题的问题，用各类“专家”们各个牵扯的部门都懂的方式描述出来。消除了对方对所有不是引起问题的问题的疑虑，总算送出去后没声音了。

文档,详细的设计说明文档! 说千万遍可能也有人不重视.那么就等着悲剧吧,早晚的事.