软件开发还算不上是一门科学 但不妨碍它是一门技术
很多大学里是把软件开发相关的专业划入工科的，这给人一种错觉，让人认为软件开发也是一个工程学科，就像土木建筑，动力机械那样。但这从根本上错了，土木建筑，动力机械的背后有确实的科学定律作为支撑，而软件开发的背后基本上什么都没有，远不是一种“科学”。
也正因此，“软件工程”的现实意义也就远不如“土木工程”，“动力工程”。
每个人对“科学”的定义可能不同，但在这里，我们可以做一个简化版的定义：当有一组在限定条件下颠扑不破的定律做支撑时，相应的知识，我们可以称之为科学，科学自身可以体现为一种确定性。比如说：牛顿的力学定律在低速时是不容违反的，是一种铁则，那基于此的各种知识就可以成为科学。
从这个视角出发，我们会发现，在软件的世界里，压根找不到属于软件的“牛顿力学定律”，有的只是杂多、纷争和不确定性。
面向对象应该是接受程度最高的分析和设计方法，但即使如此Eric Raymond和Linus也仍然会站出来批判它。
参见：
- Eric Raymond谈模块化原则，胶合层和面向对象的缺陷 孟岩译 http://blog.csdn.net/myan/article/details/1924
- C++一无是处 http://news.csdn.net/a/20100612/218785.html
简单来讲：Eric Raymond认为OO会导致过度分层，Linus认为面向对象解决的是一些小问题，他们不约而同的反对OO。你能找到如此批判牛顿定律的人么？
但Eric Raymond他们的观点又不由得你不重视，除非你认为Eric Raymond和Linus信口雌黄或人品有问题，否则你可以批判，可以不同意，但你不能忽视他们的声音。他们的声音必然基于他们的经历，代表着特定的现实，而现实本身代表合理性。
面向对象之外，各种观点想法就更多，这导致了软件的世界是杂多的，不确定的，行业中人大多都为名词所苦。
随便看一下吧，有多少人可以精确分辨这些词间的差异：
- 框架(Framework)
- 架构(Architecture)
- 面向对象分析和设计(Object Oriented Analysis and Design)
- 设计模式(Design Pattern)
- 契约式编程（Design by Contract)
- 测试驱动开发(Test Driven Development)
- 面向方面的编程（Aspect Oriented Programming)
- 模型驱动架构（Model Driven Architecture)
- 基于组件的开发（Component-Based Development）
- 敏捷软件开发(Agile Software Development)
- 元编程(Meta programming)
- 面向服务的体系结构（Service-oriented architecture）
- Feature-oriented programming
编程语言就更不要说了，实在不知道有多少个，但反过来想，世界上真需要这么多种语言么？
这些不同的方法（概念或语言）只要存在，即使彼此有冲突，也必然有其合理之根基，这里无意分析其优劣，只是想说：软件开发的定论在那里？我们究竟又该根据什么来判定那个是适合的，那个是不适合的？这种众说纷纭，真是工程学科应该有的状况么？
如果所有这一切都只能归还给当事人，那就必然纷争不断，软件开发也就一定不是一种科学。在这样一种情景下，由于任何人都可能是错的，务实的程序员也就必须选择相信自己多过相信别人，那怕别人有天大的来头。
相信自己基于事实和逻辑的分析，即使错了，也可以成为一种进步的养分；相信别人，错了不会进步，对了也是别人对了，有什么意思。狂妄的程序员则可以挑战“牛顿”这一角色。
杨昌济先生，曾经说过两句话，特别有意思，也契合软件开发的情景，因此把它放在这里，作为结尾：
- 横尽虚空，山河大地无一可恃，而可恃唯我。
- 竖尽来劫，前古后今无一可据，可据者唯有当前。