石锅拌饭 Robin Lu’s weblog

从这里看到一篇有趣的文章，叫“How Software Companies die”，是Orson Scott Card 1995年发表在Windows Sources上。Orson Scott Card是科幻小说作家，星云雨果都得过，我看过他的《安德的游戏》和《死者代言人》，可没想到他对软件开发也这么一针见血，顶得上一本The art of program management了。
节译转载:

软件公司怎么失控的和完蛋的？通常是来了一个有个性的管理人员，这老兄一看，这帮程序员怎么这么……不顺眼啊？脏兮兮，乱糟糟，不配合，他们看起来是多无趣的一群人啊！最糟糕的是，他们还笑话你！于是对他们进行管理……这下规范了，但是，程序员们被伤害了，他们被要求要参加会议，做计划，写报告，严格按照流程，千万千万不要去动别人的代码！程序员觉得自己就象过起了外星人的生活……于是，最好的程序员走了，有的开始怠工，甚至破坏……蜂房毁了。管理者舒服了，因为好像事情开始受控了，大家开始打领带了；但是Bug开始成堆出现，市场丢失，最后，关门大吉。

原文：

How Software Companies Die

By Orson Scott Card
The environment that nutures creative programmers kills management and marketing types - and vice versa. Programming is the Great Game. It consumes you, body and soul. When you’re caught up in it, nothing else matters. When you emerge into daylight, you might well discover that you’re a hundred pounds overweight, your underwear is older than the average first grader, and judging from the number of pizza boxes lying around, it must be spring already. But you don’t care, because your program runs, and the code is fast and clever and tight. You won. You’re aware that some people think you’re a nerd. So what? They’re not players. They’ve never jousted with Windows or gone hand to hand with DOS. To them C++ is a decent grade, almost a B - not a language. They barely exist. Like soldiers or artists, you don’t care about the opinions of civilians. You’re building something intricate and fine. They’ll never understand it.

BEEKEEPING

Here’s the secret that every successful software company is based on: You can domesticate programmers the way beekeepers tame bees. You can’t exactly communicate with them, but you can get them to swarm in one place and when they’re not looking, you can carry off the honey. You keep these bees from stinging by paying them money. More money than they know what to do with. But that’s less than you might think. You see, all these programmers keep hearing their parents’ voices in their heads saying “When are you going to join the real world?” All you have to pay them is enough money that they can answer (also in their heads) “Geez, Dad, I’m making more than you.” On average, this is cheap. And you get them to stay in the hive by giving them other coders to swarm with. The only person whose praise matters is another programmer. Less-talented programmers will idolize them; evenly matched ones will challenge and goad one another; and if you want to get a good swarm, you make sure that you have at least one certified genius coder that they can all look up to, even if he glances at other people’s code only long enough to sneer at it. He’s a Player, thinks the junior programmer. He looked at my code. That is enough. If a software company provides such a hive, the coders will give up sleep, love, health, and clean laundry, while the company keeps the bulk of the money.

OUT OF CONTROL

Here’s the problem that ends up killing company after company. All successful software companies had, as their dominant personality, a leader who nurtured programmers. But no company can keep such a leader forever. Either he cashes out, or he brings in management types who end up driving him out, or he changes and becomes a management type himself. One way or another, marketers get control. But…control of what? Instead of finding assembly lines of productive workers, they quickly discover that their product is produced by utterly unpredictable, uncooperative, disobedient, and worst of all, unattractive people who resist all attempts at management. Put them on a time clock, dress them in suits, and they become sullen and start sabotaging the product. Worst of all, you can sense that they are making fun of you with every word they say.

SMOKED OUT

The shock is greater for the coder, though. He suddenly finds that alien creatures control his life. Meetings, Schedules, Reports. And now someone demands that he PLAN all his programming and then stick to the plan, never improving, never tweaking, and never, never touching some other team’s code. The lousy young programmer who once worshiped him is now his tyrannical boss, a position he got because he played golf with some sphincter in a suit. The hive has been ruined. The best coders leave. And the marketers, comfortable now because they’re surrounded by power neckties and they have things under control, are baffled that each new iteration of their software loses market share as the code bloats and the bugs proliferate. Got to get some better packaging. Yeah, that’s it.

总有一些自作聪明的项目管理认为把最后期限打个折告诉开发人员会让项目按期完成。这里有篇文章告诉大家，这么做除了搞糊涂大家，可能的结果就是：

• 大家发现你在撒谎
• 大家不会再信任你
• 大家会用同样不真实的话敷衍你
• 大家会认为你每次提出的最后期限都是假的

Technical lead是团队开发的核心，职责介于技术和管理之间，是一个吃力不讨好的角色。Hacknot上有一篇文章将了做tech lead的最忌讳犯的一些错误，其中包括：

• 自认为组员服务于你
• 享受特权，脱离群众
• 沉迷于假模假势的激励技巧
• 不能提供技术方向
• 通过团队达到个人目的
• 专注于自己的个人贡献
• 试图成为技术全能
• 不能有效分配工作
• 无视自己的短处
• 脱离具体的技术工作
• 为避免冲突而无原则牺牲本组的利益
• 为了项目成功不惜一切代价
• 期望每个人都象自己一样
• 冷酷无情
• …

五一放假结束后的第一周，在一位经验丰富的美国同事带领下进行了一周的敏捷开发实践。在此之前的半年时间里也试过scrum，并且体会到了一些好处，但那一周不仅让我们体会到了好处，可以看到了敏捷开发的力量。很多书本上早读过的观点和方法在他的帮助下确确实实为我们解决了实际问题，很让人兴奋。
此后将近一个月的时间里，我们尝试延续第一周的方法，必须承认我们还不是实施敏捷开发的专家，但还是取得了以前无法想象的成果。下面是一些体会：
1。短而递进的开发周期。我在以前也提过，现在能比以前更好的采用分而治之的方法。对于一个需求，如果需要十二天来完成，那么两天我们能完成到一个什么程度，或者是一个简化的需求，或者是这个需求的一部分，只要实现的完成度可以拿出来衡量，我们就制定一个两天的计划，两天后验收，然后一步一步做下去而不是“这是需求，十二天后见！”。
2。更准确的估计工作量。估计工作量对我来说一直是一个难题。当这次我又对一个work item给出不很确定的估计时，我被反问“哪些不确定因素造成了这些不确定地工作量”，我回答那里那里可能有潜在的问题可能会导致工作量的增加，“那么如果目前不去考虑这些潜在的问题，你对工作量的估计是多少？”，我的答案马上变的确定了。对于不确定的问题，我们只需要把它记下来，在问题浮现或者变得确定后再解决，而不是把它变成包袱背在身上。能绕过这个槛是我这次最大的收获。
3。分清什么是需求，什么是实现。工程师在讨论问题的时候很容易陷入细节，以至于忘记了事情的根源，即需求。我不止一次的被提醒“你现在讨论的是需求还是具体实现”，在回答了这个问题后，很多诸如“做什么”“怎么做”的问题自然就得到了答案。
4。unit test。没有UT就不是敏捷开发，不光是为了测试，有时候只有UT才能确定你工作是否完成，才能使短而递进的开发成为可能。在这一点上我还欠缺不少。
教训也是有的，最大的教训就是我们把计划定得太激进以至于经过这三个星期我们越来越不敏捷了。40小时每周是敏捷开发的核心，此话一点不假。
最后是同事发给我们的一副图片，最真实地再现了我们的工作：

在中期review的时候发了一篇牢骚，引来了一些朋友的共鸣和反馈，一位guest朋友留言谈了他的经验：

量化工作也是职业化的一种吧。尽管我个人对此并无赞同或者反对。不过如果特别是说程序员做Object Setting，我有一点经验，不知道有用没有：最重要的当然是需要完成的项目。每个项目都会有roadmap吧？roadmap上的milestone就可以作为一个时间上比较靠谱的参考。然后开发时候，陆续把所有的任务都敲碎放到bugzilla里去。到项目结束/年度结束，考察工作其实就是review bugzilla。再不懂技术的老板，看到通过解决的所有的可预见的问题和中途修改好的bug报表（所以要用bugzilla，因为它能自动生成报表），也都会对一年的工作有数了。至于说performance，这个东西应该是相对的，而且最好是这一年度的bug报表对于上一年度的比较。说真的，这东西确实没有什么实际用处，谁会因为多写了一年程序就真的提高了多少performance，这种循序渐进的东西确实无法量化。

对目标的制定也许会很让人迷惑，我的不一定有用的经验就是写的越具体越好。百分比应该用在对项目完成度的衡量上。但是如果有百分比，就一定指出来那些没有包括进来的百分比是留在下一年了，还是有团队的其它人来完成。这对于项目管理者来说也会有帮助的。

定期review工作的好处是，可以及时发现blocking bug，并且对此做出相应的调整。但是管理者不见得能够实践后一条，这可能也不说明review工作真的没有用，只是管理者本身执行得不够好。

其实我并不反对设定目标和定期的review，我反对的是这种纯粹management oriented的长期目标设定和review。
实施敏捷开发有一段时间了，一个scrum的周期最长也就是一个月，每天都会花很短的时间做前一天的review和目标的调整。我体会到的这个过程的要点就是:review要及时，目标设定要随时调整。我对以年为跨度的object setting和performance review的最大困惑就在于两者的严重脱节。
实际上，这样长跨度的目标设定，更倾向于一个career plan而不是project或者product plan。而拿一个career plan作为年终performance review的依据，纯粹就是牛头不对马嘴。