读人月神话有感
读这本书大概就是因为名字而来，人和月代表什么呢?开篇提到软件实践工程项目的效率问题，那么我就猜测这里的人代指人数，但是月又代表什么呢？难道是月份？这个不得而知，只能继续往下阅读。下面的一大部分在阐述进度和工作量之间的关系，以大部分项目因为缺乏合理的时间分配而滞后为背景，进行了展开分析。在大多数的项目中，一但工程滞后，管理人员的第一反应就是增加人手，但是往往增加人手并不能很好的解决这个问题，因为在软件工程中，每个小分块之间的编写者都是需要沟通才能是整个项目完美完成的，如果只是增加人手，但是这些人对工程项目还不了解，还得与其他人进行沟通，这样反而更加浪费了时间。这就像用汽油灭火一样，只会使事情更加糟糕，越来越大的火势需要更多的汽油，从而进入了一场注定会导致灾难的循环。
作者将巴比伦塔失败的原因之一归结于缺乏交流，缺乏组织。而我们能从中的来的教训之一在大型软件开发，要无比重视交流的重要性。本书初版之后四十余年的现在，人们所发明的很多技术和规范很大程度上都是为了加强“交流”，减少不必要的交流，增加交流的效率——团队组织的目的是减少所需的交流和合作的数量。
为了加强交流，作者提到了文档的重要性，对这一点我也深有体会，团队组长将自己的想法及一些规划，安排甚至设计思路写成文档，团队成员可以随时浏览不至于偏离主线，对于那些和自己理念有分歧的地方也可以尽快发现，所以加强交流，文档是很重要也很有必要的工具。
在系统编程中，人数与时间的互换是一种荒谬的观点。作者举了一个十分浅显易懂的例子——无论多少个母亲，孕育一个生命都需要十个月。以为孕育生命这个进程来说，是绝对不可以分割给别人的。由于测试调试的次序问题，大部分项目都具有这个特点。