为什么巴比伦塔会失败？
清晰的目标？是的，尽管幼稚得近乎不可能。而且，项目早在遇到这个基本的限制之前，就已经失败了。人力？非常充足。材料？在美索不达米亚有着丰富的泥土和柏油沥青。足够的时间？没有任何时间限制的迹象。足够的技术？是的，金字塔、锥形的结构本身就是稳定的，可以很好分散压力负载。对砖石建筑技术，人们有过深刻的研究。同样，项目远在达到技术限制之间，就已经失败了。那么，既然他们具备了所有的这些条件，为什么项目还会失败呢？他们还缺乏些什么？两个方面——交流，以及交流的结果——组织。他们无法相互交谈，从而无法合作。当合作无法进行时，工作陷入了停顿。通过史书的字里行间，我们推测交流的缺乏导致了争辩、沮丧和群体猜忌。很快，部落开始分裂——大家选择了孤立，而不是互相争吵。
胸有成竹
一个程序员的生产效率究竟有多高？
对规模平均为3200指令的程序...大约单个的程序员所需要的编码和调试时间为178个小时，由此可以外推得到每年35800语句的生产率。而规模只有一半的程序花费时间大约仅为前者的四分之一，相应推断出的生产率几乎是每年80,000代码行1。计划、编制文档、测试、系统集成和培训的时间必须被考虑在内。因此，上述小型项目数据的外推是没有意义的。就好像把100码短跑记录外推，得出人类可以在3分钟之内跑完1英里的结论一样。工作量和代码行数不是线性关系，而是指数型关系：工作量 ＝ （常数）×（指令的数量）^1.5。对于常用编程语句而言，生产率似乎是固定的。这个固定的生产率包括了编程中需要注释，并可能存在错误的情况。生产率随着系统复杂性或者难度增加而降低。使用适当的高级语言，编程的生产率可以提高5倍。
未雨绸缪
因此，管理上的问题不再是“是否构建一个试验性的系统，然后抛弃它？”你必须这样做。现在的问题是“是否预先计划抛弃原型的开发，或者是否将该原型发布给用户？”从这个角度看待问题，答案更加清晰。将原型发布给用户，可以获得时间，但是它的代价高昂——对于用户，使用极度痛苦；对于重新开发的人员，分散了精力；对于产品，影响了声誉，即使最好的再设计也难以挽回名声。因此，为舍弃而计划，无论如何，你一定要这样做。虽然Brooks在50年前就已经提出构建可抛弃原型的必要性，并且在各类开发模型中也都强调原型的必要性，但是到今天，可抛弃原型仍然没有被大部分实践所接受。或许，知道该做什么，和实际去做之间，永远存在一个鸿沟。另一种可能性是，可抛弃原型虽然很好，但是显然没有达到“必须”的程度。它带来的好处不足以弥补其代价，是今天大部分实践中并未采用的原因。系统软件开发是减少混乱度（减少熵）的过程，所以它本身是处于亚稳态的。软件维护是提高混乱度（增加熵）的过程，即使是最熟练的软件维护工作，也只是放缓了系统退化到非稳态的进程。系统开发的熵论，非常的形象有趣。为变更而计划组织架构，其实只是一句让你认识到软件开发过程中“唯一不变的是变化”这一条真理。然而这也是一条悖论，如果只有变化的话，那么计划就没有意义了。关键在于我们需要计划出不变的部分，为变化留出空间。
祸起萧墙
项目是怎样延迟了整整一年的时间？…一次一天。但是一天一天的进度落后是难以识别、不容易防范和难以弥补的。昨天，某个关键人员生病了，无法召开某个会议。今天，由于雷击打坏了公司的供电变压器，所有机器无法启动。明天，因为工厂磁盘供货延迟了一周，磁盘例程的测试无法进行。下雪、应急任务、私人问题、同顾客的紧急会议、管理人员检查——这个列表可以不断地延长。每件事都只会将某项活动延迟半天或者一天，但是整个进度开始落后了，尽管每次只有一点点。对于这种逐渐延迟的进度，Brooks提议简历项目里程碑，并且持续的修订项目计划，这样无论最后的情况变得多么糟糕，它都不会有太大的变化。里程碑是指百分之百的事件，必须有明显的边界和没有歧义。这样就很好有人可以在里程碑进展上弄虚作假。另外一面
需要文档的必要性不言而喻，问题在于什么样的文档才是好的文档。本文中给出了以下文档必要内容的参考：目的。主要的功能是什么？开发程序的原因是什么？环境。程序运行在什么样的机器、硬件配置和操作系统上？范围。输入的有效范围是什么？允许显示的合法范围是什么？实现功能和使用的算法。精确地阐述它做了什么。输入－输出格式。必须是确切和完整的。操作指令。包括控制台及输出内容中正常和异常结束的行为。选项。用户的功能选项有哪些？如何在选项之间进行挑选？运行时间。在指定的配置下，解决特定规模问题所需要的时间？精度和校验。期望结果的精确程度？如何进行精度的检测？借鉴：https://www.jianshu.com/p/da8a68354caa
