一年前，出去和同事一块儿去Woodbine打羽毛球，我们不经意间说起了软件设计问题。
对话：
同事A：咱们买的印度公司的那套LIB库怎么样？
我：整体的架构设计是非常好的，虽然能够明显看出是融合了几个架构师的设计思路；但是，一批低水平的程序员在实现的时候太过糟糕，代码丑陋切危机四伏。系统经常随机的crash，并且很难找到真正的问题在哪里！
同事A: 好的软件设计要保证能够更容易定位bug
我：是的。
同事A：所以说，有了bug，如果很难定位，那就是软件设计出的问题！
我：不对！不能这么说；有很多case不是软件设计的问题，是软件实现带来的问题。
同事A：我不同意你的说法。
我：软件设计只能保证架构和基本流程的稳定性，一旦在实现环节出现问题有时候是很难归咎到设计上。举个例子：有些程序员在写程序的时候不初始化变量，在有些场合会出现随机数据，会导致不可预测的结果，并且，有时候因为项目规模大的关系，这类错误很难被发现。
同事A：我还是不太同意，有没有更具体详细的例子。或者，你看，这个LIB中有好多模块，去掉哪个模块，系统运行稳定后，就可以确定是哪个模块的问题。
我：这个逻辑本身就是错误的！不能因为新加入模块引起crash就把责任归咎于该模块！
同事A： why？
我：通常，真实的软件系统是比较复杂的，譬如：系统使用了多线程，新加入了一个模块，系统crash；崩溃的原因有可能不是因为新加入的模块，因为，可能原来的系统就存在问题，只不过没有特定的时序和条件，无法使这个错误出现，一旦加入了新的模块，改变了原有的时序和条件，结果就有可能把原来系统的问题暴露出来。
我：再举个例子，假设原来系统有个模块有内存越界现象（事先未知); 新加入一个模块，系统崩溃。原因就是，越界访问正好影响到了新加入的模块，破坏了它正常的地址，导致执行该模块出错，但是，问题不在这个新加入模块本身；如果去掉这个新模块，系统还是运行流畅！所以，这是实现上的问题，而不是软件设计上的问题；也就是说系统总要被实现，再好的设计都依赖于程序员的code实现；并且，通常没有完美的实现，所以程序总是有bug，并且，有些并不是软件设计的问题；软件设计不是软件开发的万能灵丹妙药！
同事A：明白了！