提高自己，迎接好的未来。
在开始任何其他文字之前，首先有必要正视一个根本现实：国内外软件开发的水平是有差距的。
这一结论的最直接证据是每一轮新技术的发起者基本上都是国外的人或公司：
从方法论（CMMI，敏捷等）到各种框架（近来很热的Hadoop等）再到新的编程语言都是如此。
总的来看这类差距似乎可以概括为“原创的缺失”，大多时候，我们只是处在一种“跟随者”的角色上。
RUP出来后我们跟谁RUP，敏捷出来我们跟谁敏捷，云计算出来后我们跟随云计算，大致如此。
年纪小的时候，会单纯的以为造成这种局面的主要原因是个人技术能力不足或努力不够。
但现在想来，这反倒是次要原因。
单以单兵能力来看，国内外的程序员群体未必就有很大的差距。
这点可以反过来看，那么多开源的库，看过代码后，那个是国内程序员看不懂并完全写不出来的？
如果说既能看懂，有足够的时间也可以自己写出来，那么大致上就不是个人技术能力的问题。
这样事情就变的有些微妙，我们也就需要在更高的视点上审视一下促成一件事情的因子。
一件事情的成败大致可以用四个维度去考量：
- 有没有意识去做 -->创新
- 有没有能力去做
- 有没有时间去做 -->环境
- 有没有动力持续去做 -->意愿和环境
排除第二点能力之外，其余三点可以大致概括为：勇为天下先的意识（创新）和创新得以生长的泥土（意愿和环境）。
这几者彼此影响，不可分割。
一提创新，很多人可能会想到其瓶颈是没有想法，进而认为差距的主要原因是意识问题。
但这很可能是错的，就我自身的观感，程序员这个群体里，现实的情形应该是想法很多，但受种种制约，实践下来的不多。
现实的需要激发了创新，也提供了实践创新的场所和养分，脱离实际需要的创新是走不远的。
这似乎只能寄希望于本土软件企业的崛起，为程序员提供相应的环境（时间+实践创新的场所），
接下来如果程序员这个群体再有实践自身追求的意愿，那么事情将会改观。
国内外差距的一个间接证据是国内软件开发的工程化的程度过于薄弱。
软件这东西过度工程化是不行的，但不工程化也一定是不行的。
先不论CMMI这种大型方法论，就说最简单的软件工程数据收集。
在这点上国外比较容易找到各种数据，比如下面这样的表格：
| 代码行/天 最低值-最高值（典型值） | |||
| 软件类型 | 10,000代码行的项目 | 100,000代码行的项目 | 250,000代码行的项目 |
| 航空电子 | 15-150(30) | 3-45(7) | 3-30(6) |
| 应用系统 | 120-2,700(450) | 30-1050(90) | 15-750(75) |
| 命令与控制 | 30-450(75) | 7-90(15) | 6-75(12) |
| 嵌入式系统 | 15-300(45) | 4.5-75(11) | 3-60(9) |
| 公众因特网 系统 | 90-1500(225) | 15-300(45) | 15-225(30) |
| 内部内联网 系统 | 225-2700(600) | 45-1050(120) | 30-750(90) |
| 微代码 | 15-120（30） | 3-30（6） | 3-15（4） |
| 过程控制 | 75-750(150) | 15-150(45) | 13-130(30) |
| 实时系统 | 15-225(30) | 3-45(7) | 3-45(6) |
| 科学系统/ 工程研究 | 75-1125(150) | 15-225(45) | 12-150(30) |
| 套装软件 | 60-750(150) | 15-150(30) | 10-120(30) |
| 系统软件/ 驱动程序 | 30-750(90) | 7-150(15) | 6-120(13) |
| 电信软件 | 30-450(90) | 7-90(15) | 6-75(7) |
即使是在日本，也有一个叫IPA这样的机构在定义各种指标，并持续收集数据。而国内似乎还没人做这类事情。
这样的话对软件开发个体而言，负面影响可能并不直观，但从整体来看却也是一种切切实实的差距。
这点上很难靠个人来推进和改善，需要有一种组织（软件协会？）来持续推进才有可能改观。
------------------------------------------------------------------------------------------------------------------------------------
理想流口号：创建超一流方法论，为培育超一流软件公司贡献力量。
理想流博客：http://blog.csdn.net/leezy_2000
)
