这里的“人月”指人数×月数，即劳动力×时间；这里的“神话”指一种理想的想法，即认为工作量=劳动力×时间，当时间有限而不能改变时，我们可以通过增加劳动力（人数）来达到预期的工作量。然而，作者通过许多事实告诉我们，这是无法实现的，这个神话终将破灭。究其根本，人不是机器，不具有线性叠加的机制，尤其是面对软件开发这样需要分解成多个部分而且处理不同部分的人之间很可能需要充分交流的复杂工作时，人数这个变量的内在复杂度会指数上升。
举个简单的例子，一个稍微复杂些的工作开始只有两个人在进行，当另外两个人在中途加入时，他们可能对已开展的工作内容、整个工作的目标以及需要的技术都不甚了解，因此就要花费时间对他们进行相应的培训，之前的两位工作者也可能需要抽出时间对两位新人进行必要的交待，然后工作才能继续进行。不仅如此，在后续工作的进程中，如果四个人两两间都有必要进行充分交流的话，那么在这一块上花费的时间又将是之前两个人工作时的六倍。总而言之，对于软件开发这样的系统性工作，一味增加人数并不能解决问题缩短工期，反而会加大内耗，产生高成本、低质量、无法满足用户需求的产品。
当然，我们小组的人数已基本确定，也将不再会变更了，但这件事情对我们来说仍具有启发意义——我们可以采取怎样的手段来减少这种内耗并提高开发效率呢？一个行之有效的方法是让团队中少数几个有才能和想法的人来编写产品手册（或者说是制定出产品的市场定位及功能），他们被称之为结构师，其余的人则是负责将这些功能实现，当然在此之前需要对整个产品体系进行合理的划分，使得各部分间尽量独立，从而减少不同部分实现人员间的纠缠。不过，更加现实情况是大家都反对专制，想提出自己的一些想法，而过多的想法势必导致产品结构的松散，开发过程的混乱以及效率的低下。因此，我们应该提倡小而精的结构师团队，而大多数人只关注怎样去实现即可。
关于调试和寻找bug，本书也提供了一些好的建议，其中不少已成为共识。调试是系统编程中很慢和较困难的部分，而漫长的调试周转时间是调试的祸根，采用交互式编程的方式能大大提高生产效率。因为机器能对我们的数据立即产生响应，这样我们能更及时的发现问题，而不用等整体工作完成后再来一个一个调试bug，通常，寻找到最后一个bug所花费的时间是找到第一个bug的许多倍。此外，在团队开发过程中，每个成员都应该有防范bug的意识，这是因为不同部分的开发者都会做出自己的一些假设，且不同人之间的假设是不匹配的，这是大多数致命的和难以察觉的bug的来源。为此，我们需要制定细致的功能定义、详细的规格说明、规范化的功能描述说明以及这些方法的实施，这样便能大大减少系统中必须查找的bug数量；在开发时也应该尽量采用自顶向下的设计理念，最大限度的将功能独立为一个个模块。