人月神话相对于构建之法来说，讲的完全就是团队作业的效率问题了。
首先，要为软件开发安排足够的时间，一个赶工出来的软件好不到哪去，因为当开发要达到约定期限时，开发者第一时间想到的往往不是加班加点把项目赶出来，而且也不现实。通常想到的都是在原项目的基础上进行各种各样的阉割，导致最后做出来的项目更像是一个半成品。
书中还提到，任务的重新分配和加入新的人员都是对软件开发的一种推迟，新的工作模式和人员磨合要花费很大的时间，所以这些东西在一个工程开始前都需要做好安排。
而且开发人员组中的人数并非越多越好，反而是越精简越少越好。因为开发人员组成的项目组是需要沟通合作的，两个人沟通起来肯定要比三个人沟通起来要高效的多，并且出现bug也更方便去追根溯源，但是精简不是极致，要组成一个能完成任务的最少项目组。
一个系统要符合可兼容性，这是第一要素，哪怕需要牺牲一些很好的设计，也要保证他的兼容性，兼容性可以大大的提高开发效率。
在软件开发过程中，要时刻保持人员之间的沟通，不然可能会出现开发人员画蛇添足导致项目分工紊乱，又或者在开发过程中遇到含糊不清的问题抱着猜测的心理去开发，导致出现错误，也有因为在开发途中或者明显的或者隐晦的修改了一些功能，导致bug的出现。
当小组为了满足小组的既定目标时，小组会采取各种方法来满足他们的小目标，但是他们没有去考虑这些改变会对整个项目这个大目标造成什么影响。
在构建之法中有提到，不存在完美的系统，在人月神话中又提到，缺陷不可能被彻底的修复，因为每一个补丁都会破坏系统的架构，就好像一根新线缠到了线团上，越来越多的线只会导致线团越来越乱，当想找回最初的线团时，早已梳理不清结构，所以没有永远可用的系统，推翻重写是完全有必要的。
在开发中，我们需要约定一个共同的编译器或者信息转换工具，不然在交流时展现的就不是个性了，是愚蠢的拖拉。
而一个工程的崩塌往往不是因为大的问题，而是因为很多小问题累计出来的
由于软件的不可见性，软件是逐步发育成长的，在这个过程中我们只能等待他问题的出现并且优化他。