五个世界

Something important is almost never mentioned in all the literature about programming and software development, and as a result we sometimes misunderstand each other.

有一样非常重要的东西从来没有编程/软件开发书籍提到过， 因此我们有时候常常误解对方。

You're a software developer. Me too. But we may not have the same goals and requirements. In fact there are several different worlds of software development, and different rules apply to different worlds.

你是软件开发者，我也是。 但我们不一定就有着同样的目标和需求。 事实上软件开发有若干完全不同的领域， 并且这些不同的领域适用不同的规则。

You read a book about UML modeling, and nowhere does it say that it doesn't make sense for programming device drivers. Or you read an article saying that "the 20MB runtime [required for .NET] is a NON issue" and it doesn't mention the obvious: if you're trying to write code for a 32KB ROM on a pager it very much is an issue!

你正在阅读一本关于UML建模的书， 并且没有任何地方提到这不适用于设备驱动开发。 或者你在阅读一篇文章，提到“20MB运行时大小[.net所需要的]绝对不是问题”而且它也明显没提到： 如果你是在为运行32KB ROM的寻呼机编码的时候，这绝对是个问题！

I think there are five worlds here, sometimes intersecting, often not. The five are:

我觉得可以分为五个领域， 有一些重叠，大部分没有。 这五个领域分别是：

            |

----------------|-------

1. Shrinkwrap |方便袋
2. Internal |内部软件
3. Embedded |嵌入式
4. Games |游戏
5. Throwaway |临时性开发

When you read the latest book about Extreme Programming, or one of Steve McConnell's excellent books, or Joel on Software, or Software Development magazine, you see a lot of claims about how to do software development, but you hardly ever see any mention of whatkind of development they're talking about, which is unfortunate, because sometimes you need to do things differently in different worlds.

如果你最近阅读了关于极限编程的书籍，如史蒂夫.麦康奈尔的著作，或Joel谈软件， 亦或是软件开发杂志， 你会看到一系列文章宣称教你如何做软件开发， 但你几乎不会看到他们提及他们谈论的是什么类型的开发，很不幸， 因为通常在不同的领域做软件开发是不一样的。

Let's go over the categories briefly.

简单回顾一下这些不同的领域。

Shrinkwrap is software that needs to be used "in the wild" by a large number of people. It may be actually wrapped in cellophane and sold at CompUSA, or it may be downloaded over the Internet. It may be commercial or shareware or open source or GNU or whatever -- the main point here is software that will be installed and used by thousands or millions of people.

方便袋软件指的是那种被很多人“随意”使用的软件。 可以是定制在手机上的，可以是从CompUSA上买的， 或者也可以从因特网上下载。 可以是商业软件，共享软件或者是开源或GNU或其他任意名堂 – 重点是软件会被成千上万的人使用到。

Shrinkwrap has special problems which derive from two special properties:

方便袋软件的问题源自于他自身的两个特性：

• Since it has so many users who often have alternatives, the user interface needs to be easier than average in order to achieve success.

• 因为它的用户通常有替代品， 如果想要成功用户界面要比一般的易用。

• Since it runs on so many computers, the code must be unusually resilient to variations between computers. Last week someone emailed me about a bug in CityDesk which only appears in Polish Windows, because of the way that operating system uses Right-Alt to enter special characters. We tested Windows 95, 95OSR2, 98, 98SE, Me, NT 4.0, Win 2000, and Win XP. We tested with IE 5.01, 5.5, or 6.0 installed. We tested US, Spanish, French, Hebrew, and Chinese Windows. But we hadn't quite gotten around to Polish yet.

• 因为它运行在如此多的电脑上，代码通常要能兼容不同计算机之间的不同。 上周有人给我寄了CityDesk的软件错误，这种错误只会出现在Windows波兰版本上，因为该版本的操作系统使用右ALT来输入特殊字符。 我们测试过Win95，95OSR2, 98, 98SE, ME, NT4.0, 2000还有XP。 我们测试过IE5.01,5.5,6.0. 我们测试了英语，西班牙语，法语，希伯来语，中文Windows。但我们确实还没怎么搞过波兰语的Windows版本。

There are three major variations of shrinkwrap. Open Sourcesoftware is often developed without anyone getting paid to develop it, which changes the dynamics a lot. For example, things that are not considered "fun" often don't get done in an all-volunteer team, and, as Matthew Thomas points out eloquently, this can hurt usability. Development is much more likely to be geographically dispersed, which results in a radically different quality of team communication. It's rare in the open source world to have a face to face conversation around a whiteboard drawing boxes and arrows, so the kind of design decisions which benefit from drawing boxes and arrows are usually decided poorly on such projects. As a result geographically dispersed teams have done far better at cloning existing software where little or no design is required.

方便袋软件有三种重要的变体。 开源软件的开发者通常没有酬劳， 因此变数最多。 例如，如果事情不是那么“有趣”的话，就可能不会被一群完全自愿的开发者重视。 开发者们也分散在世界各地， 这也导致了完全不一样的团队通信质量。 通常在这种情况下很少有面对面的在白板上画箭头方框这样的沟通。 因此那些受益于这种白板箭头方框的设计通常不适用于这样的项目。 因此地理上分散的开发团队复制现有的软件（不需要设计或者很少设计）要比开发新的软件有效率的多。

Consultingware is a variant of shrinkwrap which requires so much customization and installation that you need an army of consultants to install it, at outrageous cost. CRM and CMS packages often fall in this category. One gets the feeling that they don't actually do anything, they are just an excuse to get an army of consultants in the door billing at $300/hour. Although consultingware is disguised as shrinkwrap, the high cost of an implementation means this is really more like internal software.

咨询软件是方便袋软件的一种变体， 通常需要大量的定制和安装 因此你不得不斥巨资雇一支咨询大军来安装。 CRM和CMS方案通常就属于这一类。 人们通常会觉得他们什么也没干，不过是找个借口然后花300刀每小时雇一堆咨询师。 虽然咨询软件会伪装成包装袋软件， 这种巨额的实现花费实际上标明了它更像内部软件。

Commercial web based software such as Salesforce.com or even the more garden variety eBay still needs to be easy to use and run on many browsers. Although the developers have the luxury of (at least) some control over the "deployment" environment -- the computers in the data center -- they have to deal with a wide variety of web browsers and a large number of users so I consider this basically a variation of shrinkwrap.

商业网站 例如salesforce.com或者更多样性的eBay同样要易用而且兼容多种浏览器。 虽然开发人员可能（至少）是对“部署”环境有一定的控制 – 数据中心的电脑 – 但他们得处理各种各样的浏览器以及大量的用户。 所以我通常认为这还是方便袋软件的变体。

Internal software only has to work in one situation on one company's computers. This makes it a lot easier to develop. You can make lots of assumptions about the environment under which it will run. You can require a particular version of Internet Explorer, or Microsoft Office, or Windows. If you need a graph, let Excel build it for you; everybody in our department has Excel. (But try that with a shrinkwrap package and you eliminate half of your potential customers.)

内部软件只需要能在公司内部的电脑上运行。 这大大减轻了开发的负担。 你可以对软件最终运行的环境做大量的假设。 你可以要求一个特定版本的IE，或者是Office，或是Windows。 如果你要一张图表，大可以让Excel给你构建；我们部门的每个人都有Excel。 （不过如果你拿着这个软件去当方便袋软件 你马上就失去一般的潜在客户）

Here usability is a lower priority, because a limited number of people need to use the software, and they don't have any choice in the matter, and they will just have to deal with it. Speed of development is more important. Because the value of the development effort is spread over only one company, the amount of development resources that can be justified is significantly less. Microsoft can afford to spend $500,000,000 developing an operating system that's only worth about $80 to the average person. But when Detroit Edison develops an energy trading platform, that investment must make sense for a single company. To get a reasonable ROI you can't spend as much as you would on shrinkwrap. So sadly lots of internal software sucks pretty badly.

在这里可用性不是最重要的， 因为只有少量的人要用这个软件， 而且他们也没什么选择余地， 他们必须要用。 开发速度才更重要。 因为开发所带来的价值只会惠及一家公司， 开发所需要的资源也少的多。 微软能够花5千万美元来开发一个对个人售价80美元的操作系统。 但是当底特律爱迪生开发一个能源交易平台的时候，这种投资就必须对一家公司而言是合理的， 为了获得一个合理的投资回报率你不能像在包装袋软件开发上那样花钱。 因此悲剧的是大量的内部软件惨不忍睹。

Embedded Software has the unique property that it goes in a piece of hardware and in almost every case can never be updated. This is a whole different world, here. The quality requirements are much higher, because there are no second chances. You may be dealing with a processor that runs dramatically more slowly than the typical desktop processor, so you may spend a lot of time optimizing. Fast code is more important than elegant code. The input and output devices available to you may be limited. The GPS system in the car I rented last week had such pathetic I/O that the usability was dismal. Have you ever tried to input an address on one of these things? They displayed a "keyboard" on screen and you had to use the directional arrows to choose letters from five small matrices of 9 letters each. (Follow the link for more illustrations of this UI. The GPS in my own car has a touch screen which makes the UI dramatically better. But I digress).

嵌入式软件的独特之处在于 它最终会被烧制进一块硬件并且通常永远不会被更新。 这就是个完全不一样的领域， 这里软件产品的质量要求就要高的多， 因为没有再来一次的机会。 你可能要面对要比桌面系统运行的要慢的多的处理器， 所以你可能要花很多时间优化。 高效的代码要比优雅的代码重要。 可用的输入输出也是有限的。 我上周租的那辆车里的GPS系统的I/O如此悲催以至于根本没有可用性。 你有没有尝试过在这种东西上输入过地址？ 它们会在屏幕上显示一个键盘，然后你要用方向键来控制输入（ 你可以点击这个链接来获得关于这个UI的更多信息， 我自己车里的GPS有个触摸屏，因此可用性就好多了。当然我离题了）

Games are unique for two reasons. First, the economics of game development are hit-oriented. Some games are hits, many more games are failures, and if you want to make money on game software you recognize this and make sure that you have a portfolio of games so that the blockbuster hit makes up for the losses on the failures. This is more like movies than software.

游戏的独特之处有两点。 首先游戏开发的经济效益是面向轰动效应的。有些游戏会轰动一时，更多的是失败之作， 如果你想要在游戏软件上赚钱， 你必须要意识到这一点， 确保你有一堆游戏，这样那个引起轰动的游戏的经济效益才能弥补那堆失败的。比起软件这更像电影行业。

The bigger issue with the development of games is that there's only one version. Once your users have played through Duke Nukem 3D, they are not going to upgrade to Duke Nukem 3.1D just to get some bug fixes and new weapons. With some exceptions, once somebody has played the game to the end, it's boring to play it again. So games have the same quality requirements as embedded software and an incredible financial imperative to get it right the first time. Shrinkwrap developers have the luxury of knowing that if 1.0 doesn't meet people's needs and doesn't sell, maybe 2.0 will.

游戏软件开发更大的问题是它只有一个版本。 如果你的用户玩过的暗黑公爵3D， 他们才不会去升级到暗黑公爵3.1D来修正一些错误或获取新装备。 不出意外，一旦某人将游戏玩通， 再玩一遍就显得很无聊。 因此游戏软件有着嵌入式软件的质量要求以及沉重的财务负担而要求一次通过。 方便袋软件的开发者，相比之下，就有着这种“如果1.0没达到要求，那么2.0可以再来”的闲暇。

Finally Throwaway code is code that you create temporarily solely for the purpose of obtaining something else, which you never need to use again once you obtain that thing. For example, you might write a little shell script that massages an input file that you got into the format you need it for some other purpose, and this is a one time operation.

最后随手扔式软件代码是你为了获得其他东西而临时开发的代码， 当你获得了这样东西之后你就再也不需要这段代码了。 例如，你可能写过一个脚本来把输入文件里的内容调成某种格式来达到某种其他目的， 这是一次性的操作。

There are probably other kinds of software development that I'm forgetting.

可能还有些其他软件开发领域我记不起来了。

Here's an important thing to know. Whenever you read one of those books about programming methodologies written by a full time software development guru/consultant, you can rest assured that they are talking about internal, corporate software development. Not shrinkwrapped software, not embedded software, and certainly not games. Why? Because corporations are the people who hire these gurus. They're paying the bill. (Trust me, id software is not about to hire Ed Yourdon to talk about structured analysis.)

以下这点很重要。 不管什么时候你读到了这种全职的软件开发大师/咨询师写的关于编程方法学的文章的时候， 你几乎可以肯定他们讨论的是内部开发， 公司内部系统开发。 不会是方便袋软件开发，不会是嵌入式开发， 当然也不会是游戏。 为什么？ 因为只有集团公司才会雇这些大师。 他们会付这种账单。 （ 相信我 Id软件公司才不会雇EdYourdon来讨论什么结构化分析呢！）

Last week Kent Beck made a claim that you don't really need bug tracking databases when you're doing Extreme Programming, because the combination of pair programming (with persistent code review) and test driven development (guaranteeing 100% code coverage of the automated tests) means you hardly ever have bugs. That didn't sound right to me. I looked in our own bug tracking database here at Fog Creek to see what kinds of bugs were keeping it busy.

上个礼拜KentBeck声明说当你在做极限编程的时候你不需要软件错误最终数据库， 因为结对编程（持续的代码省察）和测试驱动的开发（保证100%代码覆盖和自动化测试）意味着你几乎不会有任何的错误。 反正我不觉得对。 我看了下我们FogCreek的缺陷追踪数据库，看看到底大部分是什么类型的错误和缺陷。

Lo and behold, I discovered that very few of the bugs in there would have been discovered with pair programming or test driven development. Many of our "bugs" are really what XP calls stories -- basically, just feature requests. We're using the bug tracking system as a way of remembering, prioritizing, and managing all the little improvements and big features we want to implement.

沉住气并且低姿态， 我觉得里面几乎没有错误是能通过结对编程或测试驱动的开发发现的。 我们大部分的“错误”实际上是极限编程成为“故事”的东西 – 基本上也就是新特性请求。 我们在用缺陷追踪系统作为一种手段来存储，优化，管理我们希望实现的大特性或小改进。

A lot of the other bugs were only discovered after much use in the field. The Polish keyboard thing. There's no way pair programming was going to find that. And logical mistakes that never occurred to us in the way that different features work together. The larger and more complex a program, the more interactions between the features that you don't think about. A particular unlikely sequence of characters ({${?, if you must know) that confuses the lexer. Some ftp servers produce an error when you delete a file that doesn't exist (our ftp server does not complain so this never occurred to us.)

大量的代码通常只有软件在领域内被大量使用后才能被发现。 波兰键盘的故事。 不可能结对编程能发现这茬。 并且逻辑上的错误从来没有通过这种方式在不同特性下显现出来。 程序越是庞大越是复杂， 你没有想过的特性方面的交互就越多。 一串特殊构造的字符串 ( {${?,如果你非要问的话)可以混淆词法分析。 有一些FTP服务器在你删除一个不存在文件的时候会报错（我们的FTP服务器不会，所以这种情况不会发生在我们头上。）

I carefully studied every bug. Out of 106 bugs we fixed for the service pack release of CityDesk, exactly 5 of them could have been prevented through pair programming or test driven design. We actually had more bugs that we knew about and thought weren't important (only to be corrected by our customers!) than bugs that could have been caught by XP methods.

我仔细的审查了每一个错误。 我们为CityDesk服务包修复的106个错误中，只有5个能够通过结对编程或者是测试驱动开发避免。 相比能被极限编程方法论发现的错误，我们实际上有更多的我们知道但觉得不重要的（ 只有被客户纠正之后） 错误。

But Kent is right, for other types of development. For most corporate development applications, none of these things would be considered a bug. Program crashes on invalid input? Run it again, and this time watch your {${?'s! And we only have One Kind of FTP server and nobody in the whole company uses Polish Windows.

但Kent也是对的， 对于其他类型的开发。 例如大部分的集团应用系统开发， 所有的这些情况都不会被视作错误。 程序在非标准输入下崩溃？再运行一次， 这次注意不要输入{${? ！ 我们只有一种FTP服务器而且公司里没有人会用波兰Windows系统。

Most things in software development are the same no matter what kind of project you're working on, but not everything. When somebody tells you about methodology, think about how it applies to the workyou're doing. Think about where the person is coming from. Steve McConnell, Steve Maguire, and I all come from a very narrow corner: the world of mass market shrinkwrap spreadsheet applications written in Redmond, Washington. As such we have higher bars for ease of use and lower bars for bugs. Most of the other methodology gurus make their living doing consulting for in house corporate development, and that's what they're talking about. In any case, we should all be able to learn something from each other.

不管你在开发什么样的项目，软件开发里大部分的东西是相同的， 当然不是所有的东西。 当有人跟你谈方法论的时候， 要考虑它是否适用于你所工作的项目。 考虑一下这个家伙的背景。 SteveMcConnel SteveMaguire 我都来特定不同领域： 在RedMond 华盛顿写出来的世界上广泛应用的包装袋电子表单软件。 对于这样的软件我们对于可用性的要求要高于我们对错误的要求。 其他领域的方法论大师以为其他集团开发提供咨询为生， 那就是他们讨论的东西。 不管怎么样， 我们都能从彼此身上学到一些东西。