模块化和组件化是软件人员的梦想，谁都想把几个模块插到一起就可以完美的运行并完成任务，但现实却相当残酷，可以运行的模块通常不能与自己想写的程序配合工作，好的源代码由于商业利益也不太容易找到，程序员只能自己另起炉灶，搭建自己的模块，但结果还是一样，做出来的东西难以让他人共享，这个现象周而复始，不断地在多个程序员身上上演。
最近有一个叫组件管理方面的项目，听起来让人毫无信心，连运行在什么平台上、给什么用户使用都不清晰，这样的组件管理有什么用？还不如就叫做文档管理算了。
书中提到一个叫考克斯的人，他创办了一家叫做Stepstone的公司，致力于向C语言系统搭造者提供插入式芯片级软件组件，最后的结论是：坏消息是这次试验显示，即便采用最新的技术，要想设计和制造既有用又真能复用的组件、为组件写文档以便于客户理解、移植组件到潮水般不断涌现的新硬件平台上、确保最新的改进或发布版本不与现存接口冲突、将组件销售到类似威廉姆斯堡枪械行业那种鼓励从头做起的价值体系，都是极其困难的。
可复用软件之梦有一个悖论：几乎总能找到一段满足大部分需要的代码。但这些拿来的代码所不能做到的部分，恰恰是项目与众不同的创新之处----也是创建这个项目的出发点。
质量三角，既好、又快、还便宜，同时满足的事情不太可能发生。
从程序员转做经理常被说成是做了“前脑叶白质切除手术”，这个术语还是从刚从《How We Decide》这本书看到过，这种手术会让患者更新丧失感情、不知爱恨悲喜。国外技术人员不愿承担项目经理这种管理岗位，而在国内正好相反，许多时候还是不会编程的人来管理。
用代码行数做判断标准只会鼓励程序员写臃肿、蹩脚的代码。
闲逛式管理MBWA(Management by wandering around)好像不能移植到软件领域中。
关于奇客的2种定义：
以（计算机）程序缺陷为食----不善社交、身有恶臭、面色苍白的偏执狂，具有奶酪刨丝器一般的人格特点。
专注于己事的人；追求技术（特别是专业技术）和梦想、不融入主流社会的人。
群件Groupware：即时通信、聊天室、缺陷跟踪、源借故传统的邮件列表等工具，个人感觉要慎用这些工具，否则你的工作时间会被这些工具吃得一干二净。
Wiki在chandler项目中也建立了起来，感觉这个chandler项目用到的工具太多，如果程序员不能合理地安排自己的时间，估计会被这些工具所淹没。
对于程序员来说，确实有一种制造工具的冲动。磨刀不误砍柴功本身没错，但程序员在磨刀的过程中会想弄到一块最好的石头，并花了大把的时间去把刀磨得吹毛断发，却忘了还要砍柴。
持续集成应该更利于产品的定期发布。
关于Linux的作者李纳斯托瓦茨的话：
别做大项目。从小项目开始，而且永远不要期望它变大。如果这么想（指做大型软件），就会做过度设计，把它想象行过于重要。更坏的情况是，你可能会被自己想象中的艰难工作所吓倒。所以要从小处起步，着力考虑细节。别去想大图景和好设计。如果项目没解决某些需求，多半就是被过度设计了。
别指望在短时间内达到大成就，我致力于Linux达13年之久，我想后面还得花上好些时间。如果一早就妄想做个大东西，可能现在还没动手呢。