Joel on Software
Painless Functional Specifications - Part 3: But... How?
by Joel Spolsky Wednesday, October 04, 2000
Now that you've read all about why you need a spec and what a spec has in it, let's talk about who should write them.
既然你已经了解了为什么你需要规范和规范包含了那些部分,让我们聊聊谁写规范。
Who writes specs?
Let me give you a little Microsoft history here. When Microsoft started growing seriously in the 1980s, everybody there had read The Mythical Man-Month, one of the classics of software management. (If you haven't read it, I highly recommend it.) The main point of that book was that when you add more programmers to a late project, it gets even later. That's because when you have n programmers on a team, the number of communication paths is n(n-1)/2, which grows at O(n2).
让我先给你讲一点微软的历史。严格来说,20世纪80年代的微软开始增长的时候,那里的每个人都读过《人月神话》 ,软件管理的经典之一。(如果你没读过,我极度推荐你去读读。) 那本书的主要观点是当你往一个延期的项目加派程序员的时候,项目会延期的更久。 因为当你的团队里有n个程序员的时候, 沟通路径为n(n-1)/2,以O(n2)渐进速度增长。
So the programmers at Microsoft were worried about how to write bigger and bigger programs, when the prevailing wisdom of the day was that adding programmers just makes things worse.
因此微软的程序员担心如何来编写越来越大的程序,因为那个时候盛行的观点认为:往项目加派程序员只会把事情搞得更糟。
Charles Simonyi, Microsoft's long time "chief architect", suggested the concept of master programmers. The idea was basically that one master programmer would be responsible for writing all the code, but he or she would rely on a team of junior programmers as "code slaves". Instead of worrying about debugging every function, the master programmer would basically just prototype each function, creating the bare outline, and then throw it to one of the junior programmers to implement. (Of course, Simonyi would be the Master Master Programmer.) The term "Master Programmer" was a bit too medieval, so Microsoft went with "Program Manager."
Charles Simonyi,微软长久以来的“首席架构师”,提出了称为“主程序员”的概念。其主要观点是:一个主程序员负责所有代码的编写,但是他或她可以依赖一个团队的初级程序员-“码奴”。主程序员基本上应该给出每个程序的原型,仅创建大致的轮廓,然后把它扔给初级的程序员去实现。 而不是自己亲自调试每一个函数。(当然,Charles Simonyi自己是主程序员。)“主程序员”的这种概念听上去太中世纪了,所以微软使用了“程序经理”这一称谓。
Theoretically, this was supposed to solve the Mythical Man-Month problem, because nobody has to talk to anyone else -- every junior programmer only talks to the one program manager, and so communication grows at O(n) instead of O(n2).
理论上,这应该可以解决“人月神话”问题的,因为没有人需要跟其他人交谈了—每个初级的程序员只和一个程序经理交流,因此交流以O(n)而非O(n2)渐进增长。
Well, Simonyi may know Hungarian Notation, but he doesn't knowPeopleware. Nobody wants to be a code slave. The system didn't work at all. Eventually, Microsoft discovered that despite the alleged Mythical Man Month, you can still add smart people to a team and get increased output, although at decreasing marginal values. The Excel team had 50 programmers when I was there, and it was marginally more productive than a team of 25 would have been -- but not twiceas productive.
恩,Simonyi也许知道如何用匈牙利符号命名规范,但他不知道人件的概念。没有人想要成为码奴。这种体系根本没有可能行得通。实际上,微软发现虽然有所谓的人月神话,但你还是可以把聪明人加入到团队里获得项目增长的输出,当然边际效值却递减了。当我还在微软的时候,Excel团队有50个程序员,边际上来讲是比25个人的团队更加有效率的, 应该是 –- 但不是两倍那么有效率。
The idea of master/slave programming was discredited, but Microsoft still had these people called program managers bouncing around. A smart man named Jabe Blumenthal basically reinvented the position of program manager. Henceforth, the program manager would own thedesign and the spec for products.
主/从编程的概念被扫地出门了,但微软还是到处保留着这些叫做程序经理的人。一个叫做Jabe Blumenthal的聪明人基本上重新发明了这种程序经理的职位。从那以后,程序经理负责产品的功能规范和设计。
Since then, program managers at Microsoft gather requirements, figure out what the code is supposed to do, and write the specs. There are usually about 5 programmers for every program manager; these programmers are responsible for implementing in code what the program manager has implemented in the form of a spec. A program manager also needs to coordinate marketing, documentation, testing, localization, and all the other annoying details that programmers shouldn't spend time on. Finally, program managers at Microsoft are supposed to have the "big picture" of the company in mind, while programmers are free to concentrate on getting their bits of code exactly right.
从那以后,微软的程序经理搜集需求,搞清楚代码应该要做什么,然后编写规范。 通常一个程序经理配有5个程序员;这些程序员负责用代码实现程序经理用规范描述的功能。程序经理同时需要协调销售,文档,测试,本地化,以及其他所有程序员不应该花时间的繁琐细节。 最后微软的程序经理应该脑海中有公司的“大方向”,而程序员可以自由地专注在把他们的代码写对。
Program managers are invaluable. If you've ever complained about how programmers are more concerned with technical elegance than with marketability, you need a program manager. If you've ever complained about how people who can write good code never do a good job of writing good English, you need a program manager. If you've ever complained about how your product seems to drift without any clear direction, you need a program manager.
程序经理是无价的,如果你曾经抱怨过程序员应该专注于技术优雅而不是销售,那么你需要个程序经理。如果你曾经抱怨过能够写得一手好代码的人绝不可能写出好英语文章,那么你需要个程序经理。如果你曾经抱怨过你的产品如何漂着找不到方向,那么你需要个程序经理。
How do you hire a program manager?
Most companies don't even have the concept of program manager. I think that's too bad. In my time, the groups at Microsoft with strong program managers had very successful products: Excel, Windows 95, and Access come to mind. But other groups (such as MSN 1.0 and Windows NT 1.0) were run by developers who generally ignored the program managers (who weren't very good anyway, and probably deserved to be ignored), and their products were not as successful.
大多数公司甚至没有程序经理的概念。这太糟糕了。在我那个年代,微软有着优秀程序员的团队有着非常成功的产品:Excel,Windows95和Access浮现在脑海里。但其他的团队(例如MSN1.0和WindowsNT1.0)由通常忽视程序经理(这些人实际上没那么好,应许应该被忽略 )的开发者运行,他们的产品就没那么成功。
Here are three things to avoid.
- Don't promote a coder to be a program manager. The skills for being a good program manager (writing clear English, diplomacy, market awareness, user empathy, and good UI design) are very rarely the skills for being a good coder. Sure, some people can do both, but they are rare. Rewarding good coders by promoting them to a different position, one that involves writing English, not C++, is a classic case of the Peter Principle: people tend to be promoted to their level of incompetence.
- Don't let the marketing people be program managers. No offense, but I think my readers will agree that good marketing people rarely have a good enough grasp of the technology issues to design products.
- Basically, program management is a separate career path. All program managers need to be very technical, but they don't have to be good coders. Program managers study UI, meet customers, and write specs. They need to get along with a wide variety of people -- from "moron" customers, to irritating hermit programmers who come to work in Star Trek uniforms, to pompous sales guys in $2000 suits. In some ways, program managers are the glue of software teams. Charisma is crucial.
- Don't have coders report to the program manager. This is a subtle mistake. As a program manager at Microsoft, I designed the Visual Basic (VBA) strategy for Excel and completely speced out, to the smallest detail, how VBA should be implemented in Excel. My spec ran to about 500 pages. At the height of development for Excel 5.0, I estimated that every morning, 250 people came to work and basically worked off of that huge spec I wrote. I had no idea who all these people were, but there were about a dozen people on the Visual Basic team alone just writing documentation for this thing (not to mention the team writing documentation from the Excel side, or the full time person who was responsible for hyperlinks in the help file.) The weird thing was that I was at the "bottom" of the reporting tree. That's right.NOBODY reported to me. If I wanted people to do something, I had to convince them that it was the right thing to do. When Ben Waldman, the lead developer, didn't want to do something I had speced out, he just didn't do it. When the testers complained that something I had speced was impossible to test completely, I had to simplify it. If any of these people had reported to me, the product wouldn't have been as good. Some of them would have thought that it's inappropriate to second-guess a superior. Other times, I would have just put my foot down and ordered them to do it my way, out of conceit or nearsightedness. As it was, I had no choice but to build consensus. This form of decision making was the best way to get the right thingdone.
The final article in my series on specs talks about how to write good specs that people want to read.
这一系列里的最后一篇文章讨论了如何写出人们想要读的功能规范。