刚开始看的时候认为是一个有关计算机神话的历史故事。但是读下去之后才发现所谓人月“就是软件开发工程中的人员和时间。
《人月神话》不同于《构建之法》从我的理解，构建之法更偏向于手把手把一个初学者带入到软件团队构造软件结构到实现软件的全过程。而《人月神话》的中心论点是在大型编程项目中，由于人员的分工和软件固有的内在困难，在十年内无法是生产率、可靠性、简洁性 取得数量级上的进步。
文章首节介绍了开发中遇见的焦油坑，就是说，表面上看起来好像没有任何一个单独的问题会导致困难， 每个都能被解决， 但是当它们相互纠缠和累积在一起的时候， 团队的行动就会变得越来越慢。 对问题的麻烦程度， 每个人似乎都会感到惊讶， 并且很难看清问题的本质。 最终导致项目进度严重滞后或者干脆以失败而告终。人们发现调试和查错往往是线性收敛的，或者更糟糕的是，具有二次方的复杂度。结果，测试一拖再拖，寻找最后一个错误比第一个错误将花费更多的时间。后一个苦恼，有时也是一种无奈——当投入了大量辛苦的劳动，产品在即将完成或者终于完成的时候，却已显得陈旧过时。可能是同事和竞争对手已在追逐新的、更好的构思；也许替代方案不仅仅是在构思，而且已经在安排了。
那么为什么会差生这种结果呢？
缺乏合理的时间进度是主要原因，它比其他所有因素加起来的影响都还大。所说的乐观主义所有的编程人员都是乐观主义者。可能是这种现代魔术特别吸引那些相信美满结局的人；也可能是成百上千琐碎的挫折赶走了大多数人，只剩下了那些习惯上只关注结果的人；还可能仅仅因为计算机还很年轻，程序员更加年轻，而年轻人总是些乐观主义者——无论是什么样的程序，结果是勿庸置疑的：“这次它肯定会运行。”或者“我刚刚找出了最后一个错误。”所以系统编程的进度安排背后的第一个假设是：一切都将运作良好，每一项任务仅花费它所“应该”花费的时间。这样就是时间上的错误估计。