1，为什么说软件的本质是概念和概念之间的关系
因为无论怎么简化，去掉实现差异，框架差异，语言差异，软件的本质最终不能再简化为一个问题域——即一些概念和他们的关系。
或者用另外一个表达式 程序 = 数据 + 逻辑
这个表达式在OO时代进化为：程序 = 对象+对象+对象…… && 对象 = 数据+逻辑
对象模型，很明显更能贴切的去表达概念和关系
2，为什么软件工程的本质是管理复杂性
软件工程一个不可避免的东西是(需求）变化
而软件是的本质是概念和概念之间的关系，这个本质类似什么，类似于中子会影响原子裂变。
所以，这导致了软件的复杂性爆炸。
这也是为什么《人月神话》作者在论述到这个本质和变化的时候说：“如果这是事实，那么终究没有银弹”。
这里切不去论证他这个论断是否正确，但是的确反应了人月神话描述的软件工程面临的诸多难题
1，软件很容易陷入泥沼
2，陷入泥沼很难纠正调控
……
复杂性我总结有三大类
1，问题域本身的复杂性
2，采用的技术方案引入的额外复杂性
3，涉及到的人和组织再引入的额外复杂性
理解了这三个复杂性，就理解了为什么软件容易陷入泥沼，因为不能控制变化发生，就不能控制复杂性爆炸；
需求变化是变化，会引发复杂性爆炸
不能尽然计划可以视为一种计划外的变化
技术变化也是变化
组织变化也是变化
这些都会极大引发复杂度变化
软件工程 本质上要解决这三个复杂性
引入这三个复杂性的同时，我引入技术熵和组织熵的概念
熵是能量中不能做功的能量
技术熵和组织熵是技术和组织在解决问题中，额外多花费的能量。
很明显，这两者越少越好。
所以，软件工程的本质是管理复杂性
1，技术熵越少越好
2，组织熵越少越好
3，良好的领域抽象，是真正的关键
4，如何去控制变化，隔离变化，适应变化，计算变化
传统的软件工程理论是无法解决这个本质问题的
我们先来看一下传统的软件工程理论是个什么东西
1，将软件按照时间阶段分为几个步骤，确保了这个划分是完备的
2，将每个步骤分配给一个或者几个角色，确保了这个划分是可执行，可管理，可组织的
3，微观上控制每一个步骤和节点的时间，风险，降低整体复杂性；提升可管理性
4，引入UML和工作协作方法（敏捷，瀑布……）来实现各个步骤之间的衔接和角色之间的衔接，确保整个理论是内洽的
这个理论，只是一个管理性的理论，没有解决任何软件工程的本质问题，只是确保了可管理性。
所以，严格按照这个理论做的话，是大概率可以提升软件的成功率的，但是效率和灵活性就难以保证了——这也是微软这种传统类型的软件公司和FG这种类型的软件公司的差异
至于正确的方式，回头慢慢聊
