程序员，就像诗人一样，几乎仅仅工作在单纯的思考中。程序员凭空运用自己的想象，来建造自己的“城堡”。很少有这样的介质——创造的方式如此灵活，如此得益于精炼和重建，如此得容易实现概念上的设想。
这句话是《人月神话》中我比较喜欢的一句话。所谓焦油坑，就是由于如同诗人一般的程序员们不断的将工作推倒重做导致的。正是因为凭空的想象居多，导致软件产品概念设计不够完整，从而使得推倒重做之后的体系结构越发庞大，最终导致软件开发人员怎么挣扎也窥探不到真正解决问题的方案。
《人月神话》一文中的核心观点是“向进度落后的项目中增加人手，只会使进度更加落后。”这也是著名的brooks法则，而这句话也充分反映了作者对于人月观念的观点，即，人月的观念是不可靠的，人力和时间在项目工作中并不是绝对的可交换关系，增加人手在软件开发的工作中并不一定能加快进度。因为软件的开发工作中，新人的加入往往需要项目的培训，新人的融入也需要时间，新成员和老成员的沟通，新成员对项目的了解，都需要时间，而人月的观念则未把这些时间计算在内，所以说，盲目的增加人手，不仅不会加快项目进度，还很有可能会拖慢进度，越多的新人加入，就意味着越多老成员分心指导新人入手项目。那么如何才能使得项目进度不落后呢？答案是，制定合理的项目进度。
在制定合理的项目进度上，需要对以下几个方面进行分析：
1、1/3计划
2、1/6编码
3、1/4构建测试和早期系统测试
4、1/4系统测试，所有的构建已完成
可以看到，测试的时间占据了项目总进度的1/2，而在我自己的团队中，大部分时间则用来编码，这也是我们需要改进的地方。
外科手术队伍一章对团队成员的经验和质量给出一个重要的度量：最好的和最差的表现在生产率上平均为10:1，在运行速度和空间上具有5:1的惊人差异！简言之，$20,000/年的程序员的生产率可能是￥10,000/年程序员的10倍。也就是说，如果团队中的成员大部分都是有经验的程序员，那么其他成员可以喝喝咖啡静候佳音了（典型的外科手术模式：一个主刀医师）。由此也可以看到，软件公司大概需要什么样的人才了。
“也就是说，同每个成员截取问题某个部分的做法相反，由一个人来进行问题的分解，其他人给予他所需要的支持，以提高效率和生产力。”这个说法完全推翻了我以前的认知，之前我一直以为一个团队需要聆听每个成员的意见或建议（虽然我们团队并没有这样做），但是读过这一篇文章以后，发现有时候平等并不是最好的选择，因为每个团队成员的能力、智力都不相同，外科手术式的队伍以及解决方案有时候更适合软件的开发，即由主要的团队成员来决定项目中的大部分内容，其他成员给出相应的意见或建议，并辅助主程序员完成相应的工作。
我们的团队模式就类似这种模式，就我自己的体验来说，总体团队内部不会出现什么分歧，一人领导多人辅助其实更加适合敏捷开发，但是我们的团队主要程序员还是少了一些，导致开发人员的压力太大，任务太重，解决办法就是将UI编码等工作交给辅助开发的人员，而主程序员负责逻辑处理的编码部分，这样就能极大的分担主程序员的压力，在任务分配上也不会显得有人无事可做或者说纯打酱油。