人月神话(The Mythical Man-Month)

作者讲的是为什么有这么多软件业项目像是陷入了焦油坑一样,越想摆脱越被束缚,这个关系到这个职业的乐趣和苦恼.

职业的乐趣

职业的苦恼


简化的brooks法则就是:往进度落后的项目中增加人手只会使得项目进度更加落后(Adding manpower to a late of software project makes it later),至于为什么作者在这章有分析。里面有一些计算我看不懂,感觉是不是计算错了,但是整体的思想很简单就是增加的人手一方面需要进行一段时间的培训,另外一方面人手的增加会带来沟通的困难. 人数和时间的互换仅仅适用于下面的情况:某个人物可以分解给参与人员,并且他们之间不需要任何相互的交流


为什么缺乏合理的进度安排如此普遍


软件进度安排经验法则

需要特别指出不为系统测试安排足够的时间简直就是一场灾难,因为延迟发生在项目快完成的时候,直到接近项目发布的日期才发现进度上面有问题。


外科手术队伍属于那种一流人才组成的小型精干的队伍,是很多年轻的软件经理所希望带领的团队,但是问题是外科手术队伍相对开发一个大型系统的话太慢了。你不希望看到一个精干的产品仅仅是几年前人们所希望的产品。为此Mills提出了一个团队的组织方式,具体还是看书,关键是要有一个首席的设计师来决定一些矛盾很多并且关键的事情


与之对应的是法国城市兰斯(reims)在建筑风格上的一致性和上面所提到的大教堂形成了鲜明的对比。设计的一致性和那些独到之处一样,同样让人们赞叹和喜悦,如同旅游指南所述,风格的一致和完整性来自8位拥有自我约束和牺牲精神的建筑师们,他们每一个人牺牲了自己的一些创意,以获得纯粹的设计。同样这不仅显示了上帝的荣耀,同时也体现了他拯救那些沉醉在自我骄傲中人们的力量


我当然不认为只有结构师才会有好的创意。新的概念经常来自于实现人员或者是用户,然而我一直试图表达并且我的所有经验让我确信,系统的概念完整性决定了其使用的难易程度。不能与系统基本概念进行整合的良好想法和特色,最好放在一边不予与考虑。如果出现了很多非常重要但是不兼容的构思,就应该抛弃原来的设计,对不同基本概念进行合并,在合并后的系统上重新开始


我观察到外部的体系结构规定实际上是增强而不是限制小组的创造性。一旦他们将注意力集中在没有人解决过的问题上,创意就开始奔涌而出。在毫无限制的实现小组中进行结构上的决策,会出现大量的争议和想法,但是但是对于具体实现的关注放而会比较少


想要成功,结构师必须注意


这里第二个系统是相对于第一个系统而言的,在设计第一个系统时,工程师总是小心翼翼地在预算和功能之间进行合理的定夺,不加入一些花哨和毫无用的用途的功能,以期待在设计第二个系统时再加入。但是在设计第二个系统,这个系统成为了创造力宣泄的出口,各种庞大的无用的功能够加入。我对Stretch系统的印象是,从某种角度而言它是一个产品线的终结。如同早期的计算机程序一样非常富有创造性,设计非常复杂但是却异常地高效。不知道为什么,同时也感觉到,它粗糙浪费缺乏优雅,并且让人觉得必定存在更好的方法可以代替它(编写很多程序的时候我也有这种想法,总感觉必定有种更一致和优雅的设计)


由于规模是软件系统产品用户成本中如此大的一个组成部分,开发人员必须设置规模的目标,控制规模,考虑减小规模的方法,就像是硬件程序员会设立元器件数量目标,控制元器件的数量想出减少零件的办法。同任何开销一样,规模本身不是坏事,但是不必要的规模是不可取的


由于缺乏空间而绞尽脑汁的编程人员,常常能够从自己的代码中挣脱出来,回顾和分析实际情况,仔细考虑程序数据最终获得非常好的结果。实际上,数据的表现形式是编程的根本


系统软件开发是减少混乱度的过程,所以它本身是出于亚稳态的。软件维护是提高混乱度的过程,即使是最熟练的软件维护工作,也只是放缓了系统退化到非稳态的进程


工欲善其事必先利其器,但是个性化的工具会使得交流和沟通困难,那么项目经理必须考虑,计划和组织的工具到底有哪些呢?首先项目的关键问题是沟通,个性化的工具妨碍而不是促进沟通。其次当机器和工作语言发生变化,技术也会随之变化,所以所有工具的生命周期都是很短的。最后毫无疑问,开发和维护公共的通用编程工具的效率更高(在这里就必须赞叹GNU的伟大了,所有的GNU/Linux上面的工具基本上都是清一色的,极大的方便了社区的开发,gcc,gdb,diff,patch,awk,sed,grep,sort,uniq,这些都是标准的工具了,在世界范围内提供了通用编程工具)


一天一天的进度落后是难以识别,不容易防范并且难以弥补。昨天某个关键人员生病了,无法召开某个会议。今天由于雷击打坏了大厦的供电变压器所有机器无法启动。明天因为工厂磁盘供货延迟了一周,磁盘例行的测试无法进行。这个列表可以不断延长,每件事情都使得某项活动延迟一天或者是半天,但是整体进度开始落后了,尽管每次只有一点点。


里程碑边界明显没有歧义,比它容易被老板核实更加重要。如果里程碑定义的非常明确无法自欺欺人的话,那么很少有人会弄虚作假。但是如果里程碑很模糊,那么老板就会常常得到一份与实际情况不符的报告。毕竟没有人愿意承受坏消息。这种做法只是为了起到缓和的作用,并没有任何蓄意的欺骗。好的里程碑对团队来说实际上是一项服务,可以用来向项目经理提出合理要求的一项服务。而模糊的里程碑式难以处理的负担。如果我们看到的,我们必须关注每一天的滞后,它们是大灾祸的基本组成元素


为了能够得到实际的进度报告,老板可以采取两种方式一种是减少角色的冲突,另外一种就是突击进行项目的进度的检查。这里记下第一种方法。首先老板必须区别行动信息和状态信息。他必须规范自己,不对项目经理可以解决的问题作出反应,并且决不在检查状态报告的时候做安排。否则信息肯定会被压制不公开。当项目经理了解到老板受到状态报告受不会惊慌,或者不会越俎代疱,他就会逐渐提交真是的结果。


现实中,流程图被鼓吹的程度远远大于它们的实际作用。我从来没有看到过一个有经验程序员在开始编写程序之前,会例行公事的编制详尽的流程图。


所有软件活动包括根本任务-打造构成抽象软件实体的复杂概念结构,次要任务-使用编程语言表达这些抽象实体,在时间和空间限制内将它们映射成为机器语言. 我认为软件开发中最困难的部分是规格说明,设计和测试这些概念的结构,而不是对概念进行表达和对实现逼真程度进行验证。从4个内在特性可以反映出来:复杂性,一致性,可变性和不可见性。


在所有被误导的科学探索中,最悲惨的莫过于对一种能够将一般金属变成金子的物质,即点金石的研究。这个由统治者不断地投入金钱,被一代代的研究者不懈追求的,炼金术中至高无上的法宝,是一种从理想化理想和普遍假设中-以为事情会像我们所认为的那样-提取出的精华。它是人类纯粹信仰的体现,人们花了大量的时间和精力来认可和接受这种无法解决的问题。即使被证明是不存在,那种寻找出路和希望能一劳永逸的愿望依然十分强烈。而沃恩重的绝大多数总是很同情这些明知不可为而为之的人的勇气,因此它们总是能够延续。所以,将圆形变成方形的论文被发表,恢复脱发的洗液被研制和出售,提高软件生产率的方法被提出并成功地推销。我们太过于倾向于遵循我们自己的乐观主义(或是发掘我们出资人的乐观主义)。我们太喜欢忽视真理的声音,而去听从万灵药贩卖者的诱惑。