大约早上6：00左右，在KeKe的Snip上看到
A product specification
A detailed user interface prototype
A realistic schedule
Explicit priorities
Active risk management
A quality assurance plan
Detailed activity lists
Software configuration management
Software architecture
An integration plan
显而易见，没有程序员什么事情。很想为他们（当然也包括我）抱不平。但是，的确coding在整个软件过程当中是最简单不过的事情了。
我不知道说什么才好，如果这样的Snip出现在McBreen的SnipSnap上，或者出现在1997年某一个程序员的主页上都会让我好理解一点。
我不知道说什么，但我实在想说太多。
我冲动得想告诉KeKe那些软件史上重要的作品：C、Unix、Emacs、LaTex、Linux、Apache都不是这样诞生的，我也想告诉KeKe我自己能够引以为自豪的微不足道的项目都是团队人性、协作的编码换来的，我想推荐KeKe去看《The Psychology of Compter Programming》、《Adaptive Software Development》、《The Pragmatic Programmer》、《XP Explained》、《Peopleware》，但最终我还是无语了。
前段时间，当一个大学的校长告诉我他要把自己大学的软件学院建成全国最大的软件蓝领生产基地时，我也无语了。
还记得托普的几万人软件航母计划吗？为什么会有争论，为什么还需争论？为什么竟然还有那么多程序员真的就去了？我们的软件企业？我们的程序员？我无语了。
我想说很多，就是不知道说什么.....

大软件中设计是70%

测试是20%

编码只是10%

开始的设计不好

后面修改的代价很大

我一直认为，人是任何活动中的最重要的因素。
但是任何东西都有两面性。过犹不及。对人、对文档都一样
在软件活动中也一样。但是成也萧和，败也萧和。软件活动中的人太多了，如果没有合适的规范怎么可以规范不同人的活动？只能是一盘散沙而已。如果文档规范过了，同样也不行。
只有合适的才是最好的。

但是铁打的营房，流水的兵。
作的人走了，后来接手的人怎么做？和谁交流？
有规范的文档可以帮助别人理解。
文档只是一个工具。是人在使用工具，而不是人在适应工具。
所以，如果没有必要，当然可以不必写文档。沙鸡何必用牛刀？合适才是最重要的。

不必拘泥于要不要写文档这个问题。换个思考方式，需要写文档吗？写了文档之后有帮助吗？如果答案是肯定的，那就写；相反，何必要做无用功，甚至得不偿失呢？

不要抗拒文档，也不必过分推崇文档这就是哦的意见。

有些交流 是需要被文档记下来的

并不是说当时说过就过了

另外

设计是70%也并非780年代的产物
现在一样存在

当有机会做大项目时就知道了

设计好了 接口好了
剩下的只是找人填空了

如果设计不好 接口不定 软件框架不定
那再什么写也是很乱 这对大软件来说是不可能的

无所谓抗拒不抗拒的，问题在于需要所谓 分析--概要设计--详细设计 如此事无巨细的文档嘛？

   文档不是不需要，而是不要企图将所有你的代码和设计的目的都依赖之。

   IMO，文档在项目中的位置，应该简洁赅要，且不应该成为指导，交流的主要工具。也不不应该成为工作中的一个重要组成部分。