多年前，面对复杂，我会感概自身能力的不足。多年后，我可能会更多地反思复杂。爱因斯坦主张凡事力求简单，但不要过于简单，大卫马梅也认为 Keep It Simple, Stupid就好。但遗憾的是，“复杂”仍然横行霸道。不是复杂代表潮流，而是因为越简单越复杂。换句话说，简单更多地是一种能力的表现。当然，在市场化的环境下，简单只是利益最大化的手段之一，不排除复杂也是某些商品利益最大化的途径。但我相信这只是少部分，按照“进化论”规律，大环境总体还是往好的方面发展。
我遇过某行业核心系统会以应用各种专业技术、功能复杂度和庞大的服务器数量为标准而号称强大，但该系统运维组做得最多的也唯一能做的运维手段却是重启。到目前为止，服务器进程挂死或宕机已经是该系统的“日经”现象。到了这种地步，其实更应该思考架构或代码层次的优化了。但系统高层责怪的却是系统运维组的各种“不专业”。归根到底，这套系统的“复杂”只是这个行业的映射，也是体制、社会的一个缩影。所以，对于雾霾治理的忧虑，不无道理。在这样的一个大环境下，更让人担忧的是，这种“复杂”往往会被误以为能力的表现。
如果对一套系统架构的了解，需要花费数周的时间，我会祈祷这套系统能运行至正常“退休”。如果说一个普通的程序员不需要对系统架构有太多的了解，我会为这套系统的稳定性和运维成本而感到压力山大。当然也不排除“以0元投标建站来欺诈后续庞大运维费用”的商业目的。还是以上述某行业核心系统为例，我曾经试问过他们的开发和运维人员对这套系统的了解程度，他们毫不犹豫且出奇一致的答复是“真正对这套系统了解的人不多”。事后我思考最多的不是这套系统的问题，而是在同样的大环境下，房子更应该担忧的是质量问题，而不是房价问题。如果以商业安全为由，不允许员工拥有“过多地”的源代码权限，那也不应该忽视员工对系统整体了解的重要性，否则迟早会为“装B”的行为付出代价。
刚开始我也会深深地质疑自己以“简单”为核心理念设计的系统架构，不过经过了时间的考验，至少证明不比复杂的坏。曾经的简单会被客户以“没有运用开源框架”而备受质疑；也曾经因接口没有使用“webservice方案”而被轻视；更试过被其他项目组同事鄙视这简单架构的支撑能力。但时间确实是检验真理的唯一标准。客户可能不知道，当前每日一亿接口访问量的系统上线到目前为止故障率为0；到后来我才知道曾经对接过我们系统的开发人员原来只懂webservice而不会写HTTP(S)+JSON；其他项目组的同事可能不知道我们的架构也使用了单例，而他们只懂Spring才有IOC和AOP。曾经羞涩的我现在变了，我更多地会以上述现象而变得更加自信。
无须质疑，“通用”的背后意味着臃肿和复杂，但通用往往被过于褒义。我现在更加坚信“创造更多思维正面碰撞的机会”是开源的目的，而非简单的开放源码。从这个角度去思考，如果开源过程能更加重视开源设计理念方面的材料，以简单易懂的表达手段呈现给大众百姓，全民参与开源也许是一种可能，带来的效果不亚于市场化对经济产生的强大冲击。如果参与开源的“门槛”减低，也不会出现以“看过源码”为目的的人，更不会为了看懂其设计理念而不得不掌握更多的知识和花费更多的精力来研究其源代码。
我始终认为，以“宏观”的视野做“微观”的事情，是社会未来趋势。我不认为博士生做农民是大材小用，我更认为这是一种“专业”的态度。一个眼神就可以“出卖”心灵，一行代码就能看出实力。广阔的视野更能接近事物的本质，本质越清晰，事物越简单。三十后竞争的不应该是加班能力，而是思考本质的能力。所以，一切简单就好，但似乎没那么简单。