樱花开了，钱塘江边的风景这些天显得格外别致。
阅读
《大教堂与集市》的经典语录
最近重新看了 《大教堂与集市》，书中有很多经典的语录，摘抄一些。
好的软件作品，往往源自于开发者的个人需要。
认同，程序员自己痛过，才可能会解决好问题。但是又有几个程序员愿意去解决问题呢？
在一个已经延期的项目上增加人手，只会让项目更加延期。”更为一般地讲，Brooks定律指出，随着开发人员数目的增长，项目复杂度和沟通成本按照人数的平方增加，而工作成果只会呈线性增长。
以前IPD的时候经常要写WBS，WBS即Work Breakdown Structure，传统项目解决复杂度最好的方案就是把复杂度拆分成简单的任务。其实这也是为什么很多公司会选择Scrum的原因，Scrum的Sprint就是一个WBS的过程。只不过Scrum是一个迭代的过程，而IPD是一个线性的过程。 但是Scrum的迭代过程是需要有一个完整的WBS的过程来支撑的。否则Scrum就会变成一个无头苍蝇的过程（可能我们目前的现状便是如此）。
设计上的完美不是没有东西可以再加，而是没有东西可以再减。
Less is more, Less is more, Less is more. 重要的事情说三遍。无论是程序员还是产品经理，有时后纯粹一些，少些花花肠子，自然事情也就简单些。
所有软件在发布时都有一个叫README或者READ.ME的文件，用于人们在首次浏览该发布版时获得指导信息，这个传统早在上世纪80年代初就已很好建立起来，甚至有时还会被写下来。
直到今天，这些显而易见的道理仍然被很多程序员所忽略。我们总是害怕新的技术、新的工具会淘汰自己，但是对已经形成的经典和标准却会视而不见……
一个协调者是否拥有卓越的原创设计能力，并不是项目成败的决定性因素，但他是否能识别出别人的优秀创意，则一定是最关键的。
项目的成功，可以不依赖项目经理，可以不依赖产品经理，可以依赖核心的开发者，但是必须依赖一个合理的识别优秀创意的协调机制，能够把优秀创意者的最佳实践得以实施。
系统中每个个体都追求自身效用的最大化，在其共生的过程中，能够自然建立起一种具备自我纠错能力的秩序，这种秩序比任何集中式规划都要精妙和高效。这里，正是“共识原则”达成的地方。
什么时候形成一个“共识原则”达到高效，什么时候反其道而行之形成“部门墙”呢？我想可能是当一个组织的目标变成了“利润最大化”，而不是“客户满意度最大化”的时候。
如果你有正确的态度，有趣的事情自然会找到你
这是来自译者的序，这正是很多问题的核心。用来作为分享的结尾，与君共勉。