写程式其实很像在做料理，身为一个工程师，
可能会遇到的情境大概是这样:
今天客户抓了只龙虾，只给一句话我要吃龙虾，
你们是专业的交由你们来料理，
于是经过一番处理后清蒸龙虾上桌了，
结果客户说，不对呀，龙虾不是应该要用炸的吗?
虽然龙虾的最初的模样与鲜味已经跑掉了
但是这尾龙虾都煮了，总不能浪费，
于是只好把这尾龙虾再拿去油炸，
客户很可能心中已经有个程式的雏形，但却无法完善的表达，
直到功能完成后实际操作，才觉得与预期不同，而进行细部检讨
但这时候工程师不太可能把原本程式码整个打掉重写
而会在原架构上进行修补与添加，而这会造成程式码复杂化
油炸过后重新端上桌，
结果客户又说，所以我说那个酱汁呢?
还好身为一个专业的宅宅，我都有看小当家，
酱汁我早就备妥了!!!
这时候客户又说，
不对呀，酱汁应该在铺上核果外衣前，就应该用鸡蛋、砂糖、牛奶调配好酱汁，
然后再用豆皮包覆呀!
有时候客户会觉得某个功能看起来很酷炫，
但实际上会增加程式的复杂度而降低稳定性，
本来只要装在碟子就可以上桌的酱汁，
被要求要包覆在龙虾上，因为复杂度上升，所以BUG的机率就提高了
同时也导致当需要重新调整酱汁比例的时候，弄破豆皮的机率增加
至于原PO的问题嘛，版友又不是当事者，谁知道呢?
如果是按照谈定的正规操作流程且干净的资料，却出现BUG，
那很可能对方没经过内部测试就释出，这个可能就有点问题，
不过我估计原PO可能也没谈到这么细去定义操作行为吧?
但只就程式会不会有bug，我是觉得有bug是很正常的事啦，
重点是在测试与验证过程中有被抓出，不至于到终端使用者造成影响就还好，
线上游戏经过千人封测，然后上线公测还不是会被找到bug。