巴别塔项目失败的原因缺乏交流和组织。缺乏交流的问题可以通过电话交流、定期的项目会议和一本共享的正式的项目工作报告书解决。项目工作报告书应该有很好的结构，及时更新，每个人都可以看到。良好的组织可以减少所需的交流量。树状结构是传统的组织方式，它是可行的，但并不一定是最有效的，因为有利于交流的组织方式应该是网状的，但是完全的网状结构因为交流量太大，也是不可行的。所以需要设计出特别的组织交流机制以克服树状结构的不足（通常可以在树状结构中连接一些虚线）。在一个大的项目中，有两个角色是很重要的，一个是生产者（producer），就是管理经理，另一个是技术总监（经理）。管理经理负责组织团队、分配工作、创建日程表等。很多时候，他建立内部交流和报告的模式，但是很多时候负责团队之外的交流。技术经理构造设计，确定模块，保证系统的统一性和概念完整性等。管理经理和技术经理需要的天赋、能力是不同的。同时具有管理天赋和强的技术天赋的人是极其少见的。思想者很少，实干家也很少，有思想家特质的实干家是最少的。只有在3至6人的小项目中，管理经理和技术经理才可以是一个人。在更大的项目中，这两个角色应该由不同人担任，因为两者都需要全身心投入。
准备估计一个编程项目的工作总量并制订进度表是很难的，因为很难根据编码时间来估算整个项目需要完成的时间。建造小系统的数据不能应用到大型系统上。据研究，若按基本语句来计算，软件的生产率基本是个常数，其原因是每个人的思考速度基本上是个常数。相比低级语言，使用一种合适的高级语言可以使生产率提高5 倍。
程序占用的内存和硬盘空间是另一个要考虑的因素。尤其是对于操作系统软件而言，占用内存大小是要考虑的重要因素。不是说只要是大程序都是不好的，但是不必要的大程序却是。因此软件编写者必须设定软件大小的目标，控制大小，设计减少大小的技巧。软件大小的目标必须包括内存大小目标和占用磁盘大小目标。在设定大小目标的同时必须规定软件要实现的功能，防止程序员以减少功能为代价来减少软件大小。在大的项目中，分小组通常只考虑自己小组的目标的实现，而不顾对用户的影响。因此的实现的整个过程中，系统架构师必须时刻保持警惕，保证系统的完整性。为完成一个完整的系统，保持用户取向的态度是编程经理最重要的功能。另外还有时间-空间权衡的问题，为使空间-时间协调，整个小组要进行编程技巧的培训。但是精巧的快的程序几乎都是由战略上的突破产生的而不是战术上的聪明。通常，这种突破是一种新的算法，更常见的，这种突破来自数据或表的重新表示。表示法是编程的本质。
一个计算机产品的主要文档包括目标（需求、需要的东西、限制、优先级）、规范（计算机手册和性能规格）、进度表、财务预算、组织结构图、空间、预测、估算、价格等。正式的文档是非常重要的：首先，将决定写下来是至关重要的，只有当一个人将自己的想法写下来的时候，不确定性、不一致性才可能凸显出来。其次，有了写出来的文档，才可能与别人交流你的决定。最后，经理的文档给他一个数据库和一个检查清单。根据正式的文档，他才会知道自己身在何处。经理每天主要的工作是交流，而不是做决定。文档将计划和已经做出的决定传达给整个团队。作为项目经理，只有一小部分时间，约20%的时间花在从外部获取信息上，所以，市场上呼声很高的的所谓“管理全部信息系统”不是建立在真正的管理实践之上的模型。
在绝大多数的项目中，第一个建构的系统几乎不可用：太慢、太大、太不好用或者三者都有。所以准备做一个要扔掉的系统是很好的打算，因为即使最好的计划第一次也不可能保证有效。关键是，管理者是否预先就打算建造一个扔掉的系统。将垃圾扔给顾客当然可以节省时间，但是是以用户的痛苦为代价，设计者在重新设计时将会分心，还有，产品的坏名声将使得好的二次设计的产品没有生存空间。所以，计划扔掉一个，因为无论如何你会扔掉的。另外，应该明白，用户的目标和需求是会改变的，所以在设计时就应该准备改变，而不是假定不变，因为唯一不变的是变化本身。不仅目标和需求会变，开发策略和技术的改变也不可避免，准备扔掉一个的观念就是承受当一个人学习的时候，他改变自己的设计。设计可变化系统的技巧包括模块化，好的子程序，模块之间全面的接口定义以及所有这些的全面文档。组织也应该能应对变化。所有的计划、里程碑和时间表都应该是有弹性的，以应对变化。然而建立一个能应对变化的组织是更难的。老板应该尽量使得管理人员和技术人员在他们的天赋允许的情况下可互换：因此，管理人员应上技术课程，技术人员应进行管理培训。在天赋允许时，高级人员应随时准备自己写代码，技术人员也应乐意进行管理。要保证这一点，不应在管理人员和技术人员中进行高低的划分，管理级别和技术级别应完全等价（Bell实验室即进行了这种实践，它废除了所有的职业头衔）。那种高级的技术人员到最后必须走上管理岗位的观念是错误的。程序维护占据开发代价的约40%。软件的维护与硬件的维护是非常不同的：软件维护通常是修复系统缺陷、增加功能、适应使用环境和配置的变化。维护的费用受用户数量的影响，越多的用户发现越多的漏洞。但是在修补漏洞的时候必须十分小心，因为在修补一个漏洞的时候有20%到50%的概率引入另一个漏洞。在修补任一个漏洞后，应该做所有全部的测试。
好的工人使用好的工具。在软件开发过程不仅需要通用的工具，还需要个性化的工具，最核心的问题是交流。使用高级语言编程可以提高生产力和调试速度，一般的反对意见（能干我所干的事、目标代码太大、目标代码太慢）都是难以成立的。交互式编程也可以提高生产力。
在没有任何代码之前，编写出的规格说明应该提交给外面的测试组以检查其完全性和简明性。最有破坏性和隐蔽的漏洞是不同模块的建构者的不匹配的假设。 Wirth提出的自上往下、逐步求精的设计方式可以有效避免许多漏洞。组件测试的方法有联机测试、内存拷贝、快照、交互式测试等方法。系统测试往往要比我们期待的要花更多的时间。系统测试也更加艰难。我们应该应该使用各组件能正常工作时再进行系统测试（而不是将许多有Bug的组件组合起来测试，即使这些 Bug是已知的），另外在进行系统测试时一次只加一个组件，如果你一次加多个组件，你将难以判断一个新的Bug的来源。
要保证一个项目的进度被大幅度推迟，制订进度表很重要。进度表由里程碑和完成的时间组成。里程碑必须具体、明确、可界定。某一里程碑要么到达，要么没有到达，不应该是80%到达的。一个程序员对于明确的里程碑是很少说谎的，如果里程碑很明显，他不能欺骗自己。长期的计划拖延是士气杀手，如果你错过一个限期，确保你在下一个限期按时完成。对于老板，当然应该把握工程的进度，但是他不应该随意行动。对于经理能够处理的问题，他不应该采取行动。小的计划和控制组可能是一个控制项目进度很好的看门狗。
软件的文档是与机器同样重要的，即使是对于极其私人的程序，说明文档也是必须的。不应该由于进度压力等任何原因忽视文档的编写。绝大多数的文档失于概述部分过于简略。程序的概述应包括目的、运行环境、输入输出的范围、函数和应用的算法、输入输出格式、操作指令、选项、运行时间、准确性。修改一段程序也需要有一段概述，应包括流程图或者子程序结构图、详细的算法描述、所有文件的说明、通过结构的概述以及对最初设计进行更改的原因的说明。传统的用流程图说明程序的方式基本已经过时，因为如果流程图超过一页，将变得极其难懂。在源代码中嵌入说明的自说明文档方式是很好的改进。使用自说明文档的方式应注意以下几点：使用程序名和变量名携带更多的文档信息；使用空间和格式来显示子程序、嵌套，增强可读性；插入必要的段落说明，尤其是在模块的开头；另外在多说明使用的原因，而不是仅仅是怎样使用，因为动机是理解的关键。