关于系统集成的设计方案（ 二 ）

原文：http://www.joelonsoftware.com/articles/HighNotes.html
中译文：http://www.ruanyifeng.com/blog/2009/07/hitting_the_high_notes.html 译者 阮一峰

joel 的这篇文章谈了“最好的程序员”的价值，软件企业“赢者通吃”的商业法则等。转移到个人方面又该怎么做那？希望能够引起一些思考，对个人的发展及规划产生一些影响。

【摘记】：
1.质量与所花费的时间基本上是不相关

2.程序员的生产率有5倍或10倍的差距

3.布鲁克斯法则:向一个已经延误的软件项目增加人手，只会使它更加延误

4.一个优秀的程序员独自完成一项任务，就不需要额外的沟通和协调。如果同样的任务让5个程序员一起完成，他们之间就必须沟通和协调。这会花掉大量时间。开发团队越小，就越能获得额外的收益。人力与工时的互换，真的是一个神话

5.用许多平庸的程序员取代少数优秀的程序员，这种做法的真正问题在于，不管平庸的程序员工作多长时间，他们做出来的东西，都无法像优秀程序员做得那样好。

6.在软件行业，三个“臭皮匠顶个诸葛亮”是行不通的。

7.做产品与做项目的区别：产品要负责整个周期的管理，追求极致，完美。一个产品可以决定一个公司的是否能够生存。做产品是一个追求完美的过程。项目满足需求是王道，他可能不是完美的，但只要是合适的就是成功的。保证上线，争取易用，拿钱走人。#非原文#

8.优秀程序员相对普通程序员不仅仅是“生产率高十倍”的问题，而是“普通”程序员永远都唱不出，开发优秀软件所需要的那种高音。

9.对于非商业性的软件，这一点并不完全试用。内部使用的软件只要合适就好。

10.在市场上排名第二，或者有一个“还不错”的产品，对你来说，就意味着失败。你的产品必须非常优异，我的意思是，好到大家愿意谈论它。想要开发优异的软件，你的唯一希望就是依靠那些真正优秀的软件天才，只有他们才能为你创造出来

11.《人月神话》（The Mythical Man-Month）。所谓“人月”就是一个人在一个月内所能完成的工作量。假如有个项目预估需要12个人月，那么派4个人来处理这个项目，理论上只要三个月就能完成。但是，Brooks认为这种换算机制在软件业中行不通，是一个神话，因为软件项目是交互关系复杂的工作，需要大量的沟通成本，人力的增加会使沟通成本急剧上升，反而无法达到缩短工时的目的。在本质上，软件项目的人力与工时是无法互换的，当项目进度落后时，光靠增加人力到该项目中，并不会加快进度，反而有可能使进度更加延后。

12.来自Brooks的《人月神话》(The Mythical Man-Month)，这本书的主要观点是：以人月为单位来衡量一项工作的规模是一个危险和带有欺骗性的神话。人月暗示着人员数量和时间是可以相互替换的，而这个致命的错误却常常是很多项目计划赖以生存的准则