软件危机史
在看MIT课件的时候看到了“软件危机”（software crisis）这个概念的不同于在Software Engineering书中所说的不同的概念。
在software engineering中软件危机是针对单个软件项目而言的，由于过多的feature和requirement，过差的management和plan，导致软件项目处于失败的边缘。
而新的概念从宏观来看软件危机，与其说是software crisis，不如说是software industry crisis；这里可并不是说软件业面临生死存亡的关头，要灭绝了要变夕阳产业，而是说软件行业在发展的过程中已经由于主流方法和思路的限制使得现实中的软件实施变得更加困难了，自然的项目失败的概率也就提高。
First Software Crisis:
第一次软件危机发生在60-70年代，当时的汇编语言还大行其道，但是却无法适应工业界的要求，开发速度之慢，工程化之差让工业界难以忍受；如果还继续用汇编的话，那么软件只能成为艺术品而不是工业品。工业品需要能够快速大规模生产，模块化，容易维护，结构简单等特点；可以产生规模优势。而很不幸，汇编语言没有一项符合，这是面向机器的语言，缺乏能让人规模化生产的能力，无法形成生产线，员工（程序员）的培训成本也很高，哪像现在在大街上随便拉个人去蓝翔技校培训3个月就可以上生产线做一线个工人了。 在这种情况下，用汇编写程序好比做中国的古代的金缕衣，需要高超的技工慢慢雕琢，而科学界和工业界却希望能够大批量的生产T-shirt来穿了——不需要那么细致，需要的是每个人都穿上衣服。
最后的结局方案就是FORTRAN和C语言的横空出世，将底层机器指令与人隔离开来，人们可以在更高层的抽象上思考问题。软件的生产效率大为提高，当然伴随着的是效率的下降：汇编写出来的程序由人来仔细优化，速度没的说，所以现在一些performance critical的程序还是会用汇编写，比如一些底层library或者一些交易系统的某些核心组件。
Second Software Crisis:
第二次软件危机大概经过了10年之后到来，到了80-90s年代，一个软件不再是一个人或者一个3-5人小团队可以handle的事情了，在大学和企业的实验室里，动不动上百万行的大项目不再像恐龙那样稀缺和罕见，而是经常的事情。抽象语言解放了程序员的生产力和想象力，人们可以像写文学小说一样将代码的长度自由发挥下去。项目的失控和一团糟也成为了家常便饭，一个软件往往不能达到客户所预期的效果（到现在也是如此）。
除了生产，软件的维护也越来越困难，以前汇编所写的软件是几乎没有bug的，因为人写出汇编的时候几乎对每一条指令都知道它在做什么；而现在，这些东西由编译器帮我们产生，同时指令数成指数增长。出现问题的概率也越来越大。
软件行业的发展受到了制约，需求决定产品线，工业界要想解决更加复杂的问题就必须以来更复杂的软件，但是人们发现现有的工具不足以创作出高质量的复杂软件，最多只能是T-shirt而已，但是现在大家出去见个客户要穿西服啊。
面向对象，设计模式以救世主的姿态站出来了，并且一直风靡到今天，今天没有哪个软件行业的人没有听过面向对象和设计模式。更多的高级语言替代了FORTRAN和C这些老前辈，C++, Java, C#都是这个时代的佼佼者。除了技术，软件工程和相关的管理理论也有了长足的发展，这些该井帮助生产流水线建立了起来，软件的质量和规模有了长足的进步，犹如从小工厂到福特公司的流水线一般，整个行业的面貌被改变了，软件行业的春天也来了，也是在这个时代，软件公司开始替代传统的硬件提供商，站到了IT科技的前沿，而其中最为出色的当属微软。越来越多复杂庞大的软件产生了，软件开始侵略普通人的生活。
Third Software Crisis:
回顾信息产业发展的历史， 硬件永远都是走在软件的前面，Intel与2005年发布了第一款PC双核处理器，开启了多核时代，同时也宣布向单核心的摩尔定律投降：继续提高主频已经是在技术上不可实现的不归路，至于原因，主要的有两个：一、散热，高密度的核心的平均单位能耗比摩尔定律以更惊人的速度随着主频增长；二、工艺，Intel最新的工艺已经达到32纳米，也就几百个原子大小，继续提升工艺在技术上的难度不说，成本收益也不划算，天价处理器是没有市场的。于是多核并行计算的时代来临了。
但是，软件之前所有的设计和工作几乎都是面向单核Uniprocessor，而这种情况使得软件在多核作用下是无法发挥出硬件的全部性能的。之前transparently的从硬件升级中获得性能提升好处的软件，这次没有那么幸运了。
在课件中，Saman Amarasinghe称之为第三次软件危机（也许他不是原创者，但我也不知道原创者是谁），从时间跨度上来说，等到真正的一统天下的并行程序编写标准best practise出来应该还要5年左右的时间，因为如果以2005年为危机的开始，那么开始的痛苦阶段持续10年，然后是10年的快速发展时期。
这次的解决方案是什么，现在还不知道，只知道要写出良好的并行程序，目前工业上无法提供解决方案，只有好的有经验的程序员能够做到，如同稀少而有价值非凡的艺术家。但是迟早，工业界就不会满足于这种古老陈旧的生产方式，必然会有人将其改进创造新的“流水线“。
—————————————————— 我是分割线 ————————————————
软件危机的历史基本讲完了，接下来讨论下为什么会有软件危机？从根本上来说都是由于硬件的进步，人们发现可以将信息产技术引用到新的场景中的潜力。比如最早的计算机甚至绘制现在的一个简单的3D物体都做不到，而现在尖端的模型已经在电影游戏工业中应用频繁。现实是如此复杂，问题也是如此之多，当人们将现实中更加困难的问题导入软件世界时，危机也就产生了。
在这里我感到有趣的是每次危机之间的性能比率，按照摩尔定律来说，每次危机之间的间隔大概在15-20年左右，硬件的性能增长在2^12=4096倍左右，也就是说我们现实中问题的分级也不是完全连续的，也差不多在10的3次到4次幂左右。因此，在硬件水平到了能够引入新的指数级的现实问题的时候，软件业就要面临危机了。最早的电脑只不过进行一些简单的科学计算，而现在大型机器用来模拟天气甚至宇宙中的星系。
工业的要求总是迫使软件去不停的进化去适应现实，第一次危机使人们尝试让软件与机器硬件之间隔离，第二次危机是的软件更加接近如最终的现实处理方案，OO的本质就是使软件更像现实。然而现在，我们却需要程序员充分的了解多核的特性才能够写出好的软件，从希望对硬件一无所知道最终又迫切的希望熟悉和了解硬件的运作，是不是有点意思。
性能是促使软件进化的因素，只有当硬件的性能到达一定程度之后才会产生对于现实更复杂问题的解决需求，才会要求有相应的来解决问题的软件。如同经济的进步一样，新的工具（蒸汽机）出现，必须要更新的方式来解放人们（程序员）的生产力；需要有新的工业模式来让程序员写出更多的软件产品来淹没我们的生活，但是如果程序员还沉浸在过去的生产方式中，就如同马车被蒸汽机，蒸汽机被内燃机和电力淘汰一样，....。进化一直发生在我们身边。
下面分享下几张有趣的图表：
density of power：
New Opportunity:
—————————————————————————————————————————————————
References:
The term software crisis was coined by F. L. Bauer at the first NATO Software Engineering Conference in 1968 at Garmisch, Germany. An early use of the term is in Edsger Dijkstra's 1972 ACM Turing Award Lecture:
