最近写的两篇关于XP的blog

I don't think so, if you have chance to pair with some of the excellent engineers on the world, I dare to say you won't think like that.

Every engineer don't like boss, me too. But please don't make that kind of joke on XP practices. At least, pair programming improve code quality, drive you learn more, force you smart, etc.

I miss those past times that I pair with some other engineers in my company.

In a word, pair programming need the two guys have similar technical capability, if you feel pressure, improve it, is there anything else to push you make progress like pair programming?

那些没有代码阅读能力的Leader，他们会更加强调文档的重要性，甚至舍本逐末，认为文档质量才是项目质量的体现。
这句话点明了本质。

怎么说得像海龟就有错一样。
姓林的朋友听到要晕掉的。

如果结对的buddy在技术、经验上形成了一定的“领导/从属”关系，那么“监督”的作用也许就会大大减弱。
btw：中国的老板喜欢用最少的人干最多的事。。。

很符合现状。其实对于一样数量的活，结对编程的效果可能比两个人分开干还要快要好，但是老板不懂，也不这么想。他们会想的是“我为什么要让两个人来一起干一个活，那不是得多发一份工资？”，他们的目标就是1个人干n个人的活，发证代码能跑通就行，代码质量他们也看不明白。

能看懂代码控制代码质量的teamleader也很多，但是能让他们那个环境，那个条件去看代码的公司很少。你想想如果从需求确认到总体设计设计、详细设计到开发、单元测试你都要干，甚至开发之前的活都是你自己干，再扔给你两个新手，告诉你从需求开始2个月之内给我一个能跑的系统。那么出来的，顶多就是一个“能跑的”系统了

这点不是很赞同！
文档是写代码时的参照，如果文档写不好，那代码怎么会写出高质量呢！
像印度、美国，代码开发的时间很短的，大部分的时间都用在文档的编写和测试上了。可以看出，LZ是从技术方向转为管理方向的。如果接触过项目的维护，比如项目的二期，三期，四期等等，再加上公司程序员的流动大，这个时候就会感觉到文档的重要性了，这点我是深有体会啊！

我想他是曲解了老庄的意思。
文档主要目的还是描述项目、代码的情况的，让人通过文档去理解和沟通的。文档要写的最好是概要、精神等，如果文档追求完美，项目的成本会大大增加。
文档写的再好，如果代码不行，还是不好。如果代码优秀，利于重构，就是文档简要了一些，再做三期等都不是问题。

这段话说的非常好，客户或者用户重视的只是可用的软件，而这个软件的架构和设计，开发过程中的各个里程碑以及记录过程的文档是他们根本不去关心的。而一个好的Leader是必需要有阅读代码的能力的。当然，我们不是说要Leader读完所有的代码，而有找出具有代表性的和流程较为复杂的代码去读。好的软件不是文档，而正是好代码的反映。