人月神话开篇讲的是早在之前开发的过程团队的投入和收获的成果不成正比，甚至投入的具有丰富经验的开发人员越多反而最终项目的进展反而越慢这样一个怪圈。很多时候我们在软件开发的这个过程中的投入往往都是由于本身的没有了解我们身处的环境，文章对开篇对产品、编程乐趣及其苦恼进行了简要的说明，这也就是我们现在编程过程中最接近我们的这些。我还记得在之前的第一次编程的过程中对编程的这个世界充满了好奇，根本不知道其中的世界，向往着开发程序的这个过程，当自己拥有这份好奇去编程的时候我总觉得自己如鱼之有水，在编程这方面上的学习并没有遇到太多的阻碍，相反，在学习的过程中我始终觉得学习得并不够我自己才不能在独立的状态下编出自己的作品，甚至在就有越多的动力，想去探索其中的奥秘。这是我第一次接触编程的领悟，大概是在高一的时候，我初次接触了C++并且完成自己的第一个软件，CS打字器。虽然现在看起来软件还存在很多的bug，但是在那个时候回忆起来看到自己的第一个软件能够展示在电脑桌面上那种自豪感奠定了我大学想选择软件工程这个专业的决心。
在很多时候，我们在软件工程中的一个项目的计量单位都是以人月这一单位来做估计的，一个项目规模是否庞大可以看他的计量单位是不是大，我们常常是以乐观的态度面对着那些项目的进程，但这比较容易导致一个问题，就是在乐观主义的情况下，似乎对项目的估计就相对比较小，从而导致的一个问题就是压在每个人身上的任务量相对而言较大。如果一开始对软件项目的预估严重不足导致在后期在截止日期前感觉到了不能完成这一项目的情况往往会用添加人手这一手段来解决问题，但是添加人手又导致了新人员的进入，新人对于软件项目的开发必须重复进行了解，从而导致了项目继续拖延，这样循环下去可能又会重复添加人手徒增人员进度进展缓慢这样一个恶性循环。
在大学的软件开发过程中，即使组成一个团队也并不是那种人数众多的队伍，往往我们实际的开发的单位也并不是以人月这样一个单位来统计，就最近与同学之间合作开发了一款软件，在时间不算太充足的情况下我们选择了对软件本身的规模进行了一定程度上的削减，即对软件本身的功能进行了一定量的删除，然而我想这种在学校对开发项目的这个过程暂且还算是合适的，但是这个解决问题的方法并不好，其中之一就是导致遇到项目赶不上计划的情况就想着偷工减料，这在软件项目的实际开发上显然是不允许的。所以我看着书中的这些例子 ，感觉在项目开展的时候就要对项目进行一个相对而已较为准确的预估是很重要的，没有做好一个预估，对人员的安排及其项目的规模做一个准确的判断那本身而言对于最终的项目开发是显然不利的，例如人员预估太少，那么对于项目而言最终就可能不能按时按质量地开发完成。规模预估太大，导致了人员投入太多，最终项目的收益会减少。而开发项目的最终目的就是为了利益，这个过程没有调节好的话，并不利于项目的开发。