「我们一直这样做开发，时间做久了，便忘了当初的本意。」
有关软件系统开发，我们谈些什么？
我们谈过程，编码规范、开发流程、同行评审、结对编程、持续集成，从瀑布到敏捷再到极限编程。
我们谈架构，企业级、J2EE、容器化、SOA（面向服务架构）、Microservices（微服务化）。
我们谈规模，大容量、高并发、大数据。
我们还谈可靠性、可用率、n个9、响应时间等等。。。
这一切的核心是什么？
先讲个电力行业的一个故事，电力的项目我没做过，对电厂的原理虽有所了解，但看见那些大规模的电站还是感觉挺复杂的。 故事是这样开始的：
记得有个给我们上培训课的主讲老师是个须发皆白的老先生，进门后掏出一堆零件放在讲台上， 一盏酒精灯、一个小水壶、一个叶片、一个铜光闪闪的小电机、一盏小灯泡。 老先生往壶里倒了些水，点燃酒精灯，不一会儿水开了，从壶嘴里喷出了蒸汽，带动叶片旋转，然后小灯泡就亮了。
他说：这就是电厂。
他还说：如果烧的是煤炭，这就是燃煤电厂；如果烧的天然气，这就是燃气电厂；
如果获得热能的方式是核裂变，这就是核电厂；如果带动叶片的能量来自水从高处流向低处，这就是水电厂。
老先生说：你们或许会问 “那我们看到的电厂怎么这么复杂”，答案其实很简单， 电力项目需要复杂系统的目的，一是为了确保安全（Safety），二是为了提高效率（Efficiency）。
安全和效率的平衡，是所有工程技术的核心。
看完这个故事，我就感觉到所谓 “大道至简” 大概就是这样的。
开发软件系统的根本在于满足需求，不能满足需求的系统本身是没有意义的。 就像一个再安全、有效率的电厂不能发电又有什么意义呢。 所以软件系统开发也就是围绕根本的基础上确保安全与提高效率。
需求作为软件的根本差异很大，需求是多样，需求也是复杂的。 一个大型 ERP 系统，一个大型仓储系统，一个大型网站系统，到底谁更复杂，没有一个定量标准，甚至都不好定性分析。 所以前面我们谈软件系统开发那么多内容都是关于 “安全” 和 “效率” 这两个围绕根本的核心。
所有软件开发的方法论，像瀑布、敏捷到极限编程围绕的是开发活动的效率问题，而编码规范、流程制定、同行评审等等则是有关开发的安全问题。 那么 SOA 化或进一步微服务化其实同时考虑到了安全与效率，服务化拆分有利于大规模开发团队的并行开发，提升了开发效率， 但上线部署复杂了降低了运维效率，但运维效率可以通过自动化来得到弥补，而开发则不可能自动化。
同理，可靠性、可用性和容灾设计这些活动都是围绕 “安全” 这个核心，而性能优化，提升响应性则是围绕 “效率”。 有些关键的软件系统必须同时兼顾 “安全” 和 “效率”，例如用在飞机、汽车内用于控制起落、刹车、油门的软件系统， 不安全或无效率造成事故是会死人的，而另外一大部分软件系统因为不安全或无效率造成的事故则死的是钱。
没有人去争论建设电厂到底是不是一门艺术，但肯定有人在争论软件开发（程序设计）到底是不是一门艺术， 但终究大部分的软件系统开发还是更偏向于工程技术。