客户资本主义的历史观察
April 21st, 2011
（商业学习读书会第一期题目：The Age of Customer Capitalism , HBR, January 2010）
以1932年Berle和Means的论文《 现代公司与私有财产 》为象征，专业管理者的出现是为了解决企业所有者在管理中的两个问题：（1）专业技能的不可靠；（2）管理策略的不稳定。（基于30年代创业者的特征，这两个问题在当时大概是普遍存在的，但这些特征本身在现代可能有很大的变化。）这个阶段被称为“管理资本主义”。
1976年Jensen和Meckling的《 企业理论 》指出管理资本主义的一个困境：专业管理者在意的是自己的收益，而非股东的收益。（HBR这篇文章没有给出案例，大概在Jensen的书里有？）这个批评给专业管理者造成了很大的压力，促使他们把“最大化股东收益”作为自己（以及企业）的座右铭。这个阶段大概被称为“股东资本主义”？
读到这一段让我产生了一个疑问：从32年到76年之间的四十多年，股东们都干嘛去了？有鉴于（1）人都是自私的；（2）专业管理者具有远强于企业主的专业技能，这种假公济私应该会很快出现，而不是等到四十年后才被专业管理者们想起来。中间这段时间发生的事，可能在Jensen的批评中会提到？
实施股东资本主义（即：股东利益至上）最直接的方式就是让专业管理者成为股东，这正是通用电气对杰克·韦尔奇做的事：到2001年退休时，韦尔奇拥有市值9亿美元的GE股票。但这篇文章认为，这种策略并没有让股东得到最大收益。数据：1933年到1976年，标普500指数年均收益率7.6%；1977年到2008年，年均收益率5.9%。作者的结论：股东资本主义在对股东的回报上，没有表现得比管理资本主义更好。
在这里出现了一个模糊的词：“股东权益”。股东本身就分为两种不同的态度：长期投资者和短期投机者。对股票行情有着不切实际的期望、不惜损害长期收益而博取短期收益的，是投机型的股东。作者也指出：这种股东的期望是不可能满足的。而投资型股东乃至对企业有归属感、拥有感的持股人并没有这种期望。缺乏对这两类股东的区分，给后面更深的逻辑困难埋下了一个伏笔。
这里还出现了一个逻辑困难：由“收益率的下降”是否能推出“股东资本主义的失败”？根据现有信息，似乎只能说“股东资本主义的兴起”和“收益率的下降”两件事在时间上有重合。但作者针对杰克·韦尔奇的评价显得很有说服力：“透过GE的历史股价图你才能明白，韦尔奇的‘面向退休’的股权激励产生了怎样的影响。他的继任者杰夫·伊梅尔特显然是继承了一家受伤的公司。”
由此作者推出的结论是：现代商业应该进入“客户资本主义”的时代。企业（以及专业管理者）应该把客户满意度作为首要目标，从而建立具有持续性的业务模式，股东的权益也会因此而受益。然而这个最重要的推论在我看来却存在一个最严重的逻辑困难：投机型股东的权益固然是不需要过多考虑的（正如作者指出的，他们自己会用货币投票），但“避免投机型股东影响企业行为”却推不出“应该以客户权益最大化为目标”的结论。
事实上作者给出的解决方案也指向同一方向。以雷富礼为例，更长的股权兑现周期用意很明显：将CEO与长期投资型股东绑定，避免为增加短期投机型股东的收益而损害业务延续性。作为一个方针，这里面完全不需要“客户”的存在，只需要强调“以长期投资型股东的权益为根本”就可以得到同样的结果。
简而言之，作者做了很好的历史观察，但没有做很好的推理。可能作者太希望自己生活在某个大时代，但仅就这篇文章而言，所谓“客户资本主义”，其实只是股东资本主义的自我完善，而不是一个新的时代。
Why Is 100% Test Coverage Easier To Achieve?
April 17th, 2011
Some say that “it’s little valuable to achieve test coverage over 80%” (or 60% in some cases). From the perspective of quality assurance, maybe it’s true. However, from a lean perspective, 100% test coverage could be even easier to achieve than 80% (and much easier than 60%). Sounds weird? I’ll explain.
The most common argument against “100% coverage” is “Do we really need test trivial methods such as getter/setter?” But it’s a bad question. What really matters is not “do we really need test them”, but “do we really need write them”. I saw programmers wrote (or even generated) getter/setters without test just because doing so is cheap. But these small pieces of code are waste: not only because you need maintain them, but also because they (potentially) break design principles such as Law of Demeter . Creating trivial methods without test-driven is over production. It’s MUDA .
And the tolerance of code-without-test causes MURA (meaning irregular, uneven or inconsistent). Lower the bar of test coverage to 80% (or even 60%), and you’ll end up to solve code-without-test in a bigger batch. It requires more consideration and effort every time you doing it, and this effort is not split into every story (or even better, every commit) evenly. You’ll need a concentrated hour (or worse, half day) to write tests for code committed a few days ago.
And as we all know, MUDA and MURA causes MURI (overburden, unreasonableness or absurdity). When it comes to the last day before your release and suddenly test coverage drops under the bar, how possible can you get a concentrated hour to fix it? Isn’t it annoying to be requested writing some test to fix broken continuous integration when you are ready to pack your laptop and go home at 6PM? Are you going to do some serious code review before typing in yet another non-sense test case and commit it?
Allowing MUDA to accumulate causes MURA. MURA plus delivery pressure causes MURI. MURI stops you from improving code quality and causes more MUDA. The lower the bar, the worse the case. You can break the chain by eliminating every piece of code-without-test continuously. Test-driven every piece of code.
Bottom line: although it might be little valuable to tighter test coverage restriction from 80% to 100% from a quality assurance point of view, doing so makes your life easier (instead of harder). So, why not doing it?
DevOps来了
April 16th, 2011
（本文系InfoQ中文站电子期刊 架构师[2011年四月刊] 之主编寄语 ）
经过几年的酝酿，敏捷和运维这两个领域终于各自受到了足够的重视，并顺理成章地有了交集。从2009年起，一阵被称为”DevOps”的风潮从欧洲发端，迅速席卷了北美和澳洲──现在以Flickr、Twitter为代表的一干互联网公司竞相以快速发布、频繁发布为荣：这厢Flickr做个PPT叫”每天10次部署”，那边Twitter就在演讲里有意无意地说”每天部署几十次”。一说起做互联网，你要是还在走俩月一个版本的发布周期呀，你都不好意思跟人打招呼──等你做出新版本，用户都跑竞争对手那儿去啦。
顾名思义，”DevOps”就是开发和运维要搞到一块去──每天部署十几次，这两组人是得搞到一块去，不然光是填流程单的时间都不够。凡是参与过流程改进的人都知道，”搞到一块去”这事永远都是说起来容易做起来难。开发和运维，工作的环境不同，沟通的方式不同，使用的工具不同，通常还隶属不同部门，没有点方法套路，说一句”你们要紧密协作”半点用都顶不上。不过，办法总比困难多：流程、技术、工具三管齐下，一点点改进现状，最终达到交付与运维紧密无间的企业文化，至少已经有先例告诉我们是可行的。
IT技术的潮流，向来是澳洲比英美慢两三年，中国又比澳洲慢两三年。于是很自然地，当别人开始热火朝天地讲DevOps，咱们这儿”敏捷运维”还是几家互联网巨头的王谢堂前燕。不过正因为这个潮流时差，也不难预测，两三年后”敏捷运维”一定会像今天的”敏捷”一样飞入百姓家。所以呢，咱们得从现在开始早做准备──比如看看本期《架构师》精选的几篇文章，先大概了解一下这”敏捷运维”讲的到底是个啥，然后开始做一点思考和分享。等更多企业开始意识到敏捷运维的重要性，咱不就已经成竹在胸了么。
光与暗的一体两面
April 8th, 2011
最近两天，看了一些颇丑陋的事，给新同事介绍咨询业务也讲了一些挺灰暗的东西，又看到云风回忆 他的网易十年 也不尽是情意绵绵。可能这就是年纪大一点的好处：能明白所有鲜衣怒马的下面总会有几块或痛或痒的疮疖，也能勉强接受而不至于马上就要拂袖而去。
但是同时也不会因为阴暗面的存在就放弃做些有意义的事。大概这是一体两面：曾经在不那么干净的环境（或者干脆就是焦油坑）里努力尝试过，就会懂得阴影总是会在的，光线也总是可以追求的。不仅学着君子远危墙，也学着知其不可为而为，这样算是更好的中庸吧。毕竟乘桴浮于海总是容易的，难事又留给谁来做呢？
在机场读完了Xiao转发的讨论串。每个精彩传奇的背后总有些狗血的破事，但毕竟不是每坨狗血的破事都能成就一个精彩的传奇。所以，还是只管＂GO TEAM＂吧。
（谨以此文答myan问）
Collaborate with Monitors
April 5th, 2011
( Copied from Continuous Delivery )
Every operations team has some way of monitoring their production environments. They might have OpenNMS, or one of the alternatives such as Nagios or HP’s Operations Manager. Perhaps they have created their own custom monitoring system. Whichever system they use, they will want your application to hook into it so that they know the moment any error condition occurs, and where to look for more details to determine what has gone wrong.
It is important to find out, right at the beginning of the project, how the operations team expects to monitor your application, and make it part of your release plan. What do they want to monitor? Where are they expecting your logs to be? What hooks should your application use to notify operations staff of malfunctions?
