Have you ever heard of SEMA? It’s a fairly esoteric system for measuring how good a software team is. No, wait! Don’t follow that link! It will take you about six years just to understand that stuff. So I’ve come up with my own, highly irresponsible, sloppy test to rate the quality of a software team. The great part about it is that it takes about 3 minutes. With all the time you save, you can go to medical school.
The neat thing about The Joel Test is that it’s easy to get a quick yes or no to each question. You don’t have to figure out lines-of-code-per-day or average-bugs-per-inflection-point. Give your team 1 point for each “yes” answer. The bummer about The Joel Test is that you really shouldn’t use it to make sure that your nuclear power plant software is safe.
A score of 12 is perfect, 11 is tolerable, but 10 or lower and you’ve got serious problems. The truth is that most software organizations are running with a score of 2 or 3, and they need serious help, because companies like Microsoft run at 12 full-time.
Of course, these are not the only factors that determine success or failure: in particular, if you have a great software team working on a product that nobody wants, well, people aren’t going to want it. And it’s possible to imagine a team of “gunslingers” that doesn’t do any of this stuff that still manages to produce incredible software that changes the world. But, all else being equal, if you get these 12 things right, you’ll have a disciplined team that can consistently deliver.
I’ve used commercial source control packages, and I’ve used CVS, which is free, and let me tell you, CVS is fine. But if you don’t have source control, you’re going to stress out trying to get programmers to work together. Programmers have no way to know what other people did. Mistakes can’t be rolled back easily. The other neat thing about source control systems is that the source code itself is checked out on every programmer’s hard drive — I’ve never heard of a project using source control that lost a lot of code.
By this I mean: how many steps does it take to make a shipping build from the latest source snapshot? On good teams, there’s a single script you can run that does a full checkout from scratch, rebuilds every line of code, makes the EXEs, in all their various versions, languages, and #ifdef combinations, creates the installation package, and creates the final media — CDROM layout, download website, whatever.
If the process takes any more than one step, it is prone to errors. And when you get closer to shipping, you want to have a very fast cycle of fixing the “last” bug, making the final EXEs, etc. If it takes 20 steps to compile the code, run the installation builder, etc., you’re going to go crazy and you’re going to make silly mistakes.
For this very reason, the last company I worked at switched from WISE to InstallShield: we required that the installation process be able to run, from a script, automatically, overnight, using the NT scheduler, and WISE couldn’t run from the scheduler overnight, so we threw it out. (The kind folks at WISE assure me that their latest version does support nightly builds.)
我的意思是：从最新的源代码快照制作出一个可发布的构建需要多少步骤？在高效的团队中，你只需运行一个脚本就可以完成全新的检查，重新构建每一行代码，创建各种版本、语言和 #ifdef 组合的可执行文件，创建安装包并创建最终媒体，如 CD-ROM 布局、下载网站等。
如果这个过程需要超过一个步骤，那么就容易出错。当你即将发布时，你希望能够快速修复“最后”一个 bug，制作最终的可执行文件等。如果编译代码需要 20 步，运行安装程序构建器等，你会感到非常疯狂，也容易犯错误。
正因为如此，我曾经工作的公司从 WISE 切换到了 InstallShield：我们要求安装过程能够自动从脚本运行，通过 NT 计划程序在夜间自动运行，而 WISE 不能在计划程序中在夜间运行，所以我们放弃了它。（WISE 的工作人员向我保证，他们的最新版本支持夜间构建。）
When you’re using source control, sometimes one programmer accidentally checks in something that breaks the build. For example, they’ve added a new source file, and everything compiles fine on their machine, but they forgot to add the source file to the code repository. So they lock their machine and go home, oblivious and happy. But nobody else can work, so they have to go home too, unhappy.
Breaking the build is so bad (and so common) that it helps to make daily builds, to insure that no breakage goes unnoticed. On large teams, one good way to insure that breakages are fixed right away is to do the daily build every afternoon at, say, lunchtime. Everyone does as many checkins as possible before lunch. When they come back, the build is done. If it worked, great! Everybody checks out the latest version of the source and goes on working. If the build failed, you fix it, but everybody can keep on working with the pre-build, unbroken version of the source.
On the Excel team we had a rule that whoever broke the build, as their “punishment”, was responsible for babysitting the builds until someone else broke it. This was a good incentive not to break the build, and a good way to rotate everyone through the build process so that everyone learned how it worked.
Read more about daily builds in my article Daily Builds are Your Friend.
当使用源代码控制时，有时候一个程序员会意外提交了一些导致构建失败的东西。例如，他们添加了一个新的源代码文件，在他们自己的机器上一切都编译正常，但他们忘记将该源代码文件添加到代码仓库中。于是他们锁定自己的机器然后回家，毫不知情地感到开心。但其他人无法继续工作，所以他们也只能不高兴地回家。
构建失败非常糟糕（也很常见），因此进行每日构建有助于确保没有任何故障被忽视。在大型团队中，确保故障被立即修复的一个好方法是在每天的午餐时间进行每日构建。大家在午餐前尽可能多地提交检入。回来后，构建就完成了。如果构建成功，太好了！每个人都检出最新版本的源代码并继续工作。如果构建失败，你修复它，但每个人都可以继续使用构建之前的未出错版本的源代码进行工作。
在 Excel 团队中，我们有一个规定，谁破坏了构建，作为“惩罚”，就要负责看管构建，直到有其他人破坏它。这是一个很好的激励措施，不破坏构建，并且也是让每个人轮流参与构建过程，以便每个人都学会如何进行构建。
在我的文章《每日构建是你的朋友》中可以了解更多关于每日构建的内容。
I don’t care what you say. If you are developing code, even on a team of one, without an organized database listing all known bugs in the code, you are going to ship low quality code. Lots of programmers think they can hold the bug list in their heads. Nonsense. I can’t remember more than two or three bugs at a time, and the next morning, or in the rush of shipping, they are forgotten. You absolutely have to keep track of bugs formally.
Bug databases can be complicated or simple. A minimal useful bug database must include the following data for every bug:
If the complexity of bug tracking software is the only thing stopping you from tracking your bugs, just make a simple 5 column table with these crucial fields and start using it.
For more on bug tracking, read Painless Bug Tracking.
我不在乎你说什么。如果你在开发代码，即使是一个人的团队，如果没有一个有组织的数据库列出代码中所有已知的错误，你将会发布低质量的代码。许多程序员认为他们可以把错误列表记在脑子里。荒谬。我只能记住两三个错误，第二天或者在发布的紧张中，它们就被忘记了。你绝对必须正式地跟踪错误。
错误数据库可以是复杂的或简单的。一个最基本有用的错误数据库必须为每个错误包含以下数据：
如果跟踪错误的软件的复杂性是唯一阻止你跟踪错误的事情，只需创建一个简单的五列表格，包含这些关键字段并开始使用它。
想了解更多关于错误跟踪的内容，请阅读《Painless Bug Tracking》。
The very first version of Microsoft Word for Windows was considered a “death march” project. It took forever. It kept slipping. The whole team was working ridiculous hours, the project was delayed again, and again, and again, and the stress was incredible. When the dang thing finally shipped, years late, Microsoft sent the whole team off to Cancun for a vacation, then sat down for some serious soul-searching.
What they realized was that the project managers had been so insistent on keeping to the “schedule” that programmers simply rushed through the coding process, writing extremely bad code, because the bug fixing phase was not a part of the formal schedule. There was no attempt to keep the bug-count down. Quite the opposite. The story goes that one programmer, who had to write the code to calculate the height of a line of text, simply wrote “return 12;” and waited for the bug report to come in about how his function is not always correct. The schedule was merely a checklist of features waiting to be turned into bugs. In the post-mortem, this was referred to as “infinite defects methodology”.
To correct the problem, Microsoft universally adopted something called a “zero defects methodology”. Many of the programmers in the company giggled, since it sounded like management thought they could reduce the bug count by executive fiat. Actually, “zero defects” meant that at any given time, the highest priority is to eliminate bugs before writing any new code. Here’s why.
In general, the longer you wait before fixing a bug, the costlier (in time and money) it is to fix.
For example, when you make a typo or syntax error that the compiler catches, fixing it is basically trivial.
When you have a bug in your code that you see the first time you try to run it, you will be able to fix it in no time at all, because all the code is still fresh in your mind.
If you find a bug in some code that you wrote a few days ago, it will take you a while to hunt it down, but when you reread the code you wrote, you’ll remember everything and you’ll be able to fix the bug in a reasonable amount of time.
But if you find a bug in code that you wrote a few months ago, you’ll probably have forgotten a lot of things about that code, and it’s much harder to fix. By that time you may be fixing somebody else’s code, and they may be in Aruba on vacation, in which case, fixing the bug is like science: you have to be slow, methodical, and meticulous, and you can’t be sure how long it will take to discover the cure.
And if you find a bug in code that has already shipped, you’re going to incur incredible expense getting it fixed.
That’s one reason to fix bugs right away: because it takes less time. There’s another reason, which relates to the fact that it’s easier to predict how long it will take to write new code than to fix an existing bug. For example, if I asked you to predict how long it would take to write the code to sort a list, you could give me a pretty good estimate. But if I asked you how to predict how long it would take to fix that bug where your code doesn’t work if Internet Explorer 5.5 is installed, you can’t even guess, because you don’t know (by definition) what’s causing the bug. It could take 3 days to track it down, or it could take 2 minutes.
What this means is that if you have a schedule with a lot of bugs remaining to be fixed, the schedule is unreliable. But if you’ve fixed all the known bugs, and all that’s left is new code, then your schedule will be stunningly more accurate.
Another great thing about keeping the bug count at zero is that you can respond much faster to competition. Some programmers think of this as keeping the product ready to ship at all times. Then if your competitor introduces a killer new feature that is stealing your customers, you can implement just that feature and ship on the spot, without having to fix a large number of accumulated bugs.
微软的第一个适用于Windows的Microsoft Word版本被认为是一项“死亡行军”项目。它花费了很长时间，不断地拖延。整个团队都在荒谬的工作时间中工作，项目一再被延迟，压力无比巨大。当这个该死的东西终于发布时，已经晚了几年，微软将整个团队送到坎昆度假，并进行了一次认真的内省。
他们意识到，项目经理一直坚持按照“进度表”来推进，程序员只是匆忙地编写了极其糟糕的代码，因为调试修复阶段并不是正式进度表的一部分。他们没有努力控制缺陷数量，相反，据说有个程序员负责编写计算文本行高度的代码，只是简单地写了“return 12;”，等着看他的函数有没有问题的bug报告。进度表只是一个等待变成漏洞的功能清单。在事后总结中，这被称为“无穷缺陷方法论”。
为了纠正这个问题，微软全面采用了所谓的“零缺陷方法论”。公司里的许多程序员都傻笑了起来，因为听起来好像管理层认为他们可以通过行政命令来减少缺陷数。实际上，“零缺陷”意味着在编写任何新代码之前，消除缺陷是最高优先级。以下是原因：
一般来说，您在修复缺陷之前等待的时间越长，修复的代价（包括时间和金钱）就越高。
例如，当您犯了一个编译器能够捕捉到的拼写错误或语法错误时，修复它基本上是微不足道的。
当您在第一次尝试运行代码时发现了一个错误，您将能够很快修复它，因为所有的代码还在您的脑海中。
如果您在几天前编写的一些代码中发现了一个错误，您将需要一些时间来查找它，但当您重新阅读您编写的代码时，您会记得一切，并且能够在合理的时间内修复该错误。
但是，如果您在几个月前编写的代码中发现了一个错误，您可能已经忘记了关于那段代码的很多事情，而且修复起来更困难。到那时，您可能正在修复其他人的代码，而他们可能正在阿鲁巴度假，这种情况下修复错误就像在进行科学研究一样：您必须缓慢、有条不紊、一丝不苟，并且无法确定发现解决方案需要多长时间。
如果您在已经发布的代码中发现了一个错误，修复它将会产生巨大的开销。
这就是立即修复错误的原因之一：因为它需要更少的时间。还有另一个原因，与以下事实有关：相对于修复现有错误，你更容易预测编写新代码需要多长时间。例如，如果我问你预测编写一个对列表进行排序的代码需要多长时间，你可以给出一个相当准确的估计。但是如果我问你如何预测修复那个bug所需的时间，即当安装了Internet Explorer 5.5时，你的代码无法正常工作的bug，你甚至无法猜测，因为你不知道（根据定义），是什么导致了这个bug。追踪它可能需要3天，也可能只需要2分钟。
这意味着，如果您的进度表上还有很多待解决的错误，那么进度表是不可靠的。但是，如果您已经修复了所有已知的错误，剩下的只是新代码，那么您的进度表将会非常准确。
保持缺陷数量为零的另一个好处是，您可以更快地应对竞争。一些程序员将其视为始终保持产品随时可供出货的状态。因此，如果您的竞争对手推出了一个抢先的新功能，正在夺走您的客户，您可以立即实施该功能并立即发货，而无需修复大量积累的错误。
Which brings us to schedules. If your code is at all important to the business, there are lots of reasons why it’s important to the business to know when the code is going to be done. Programmers are notoriously crabby about making schedules. “It will be done when it’s done!” they scream at the business people.
Unfortunately, that just doesn’t cut it. There are too many planning decisions that the business needs to make well in advance of shipping the code: demos, trade shows, advertising, etc. And the only way to do this is to have a schedule, and to keep it up to date.
The other crucial thing about having a schedule is that it forces you to decide what features you are going to do, and then it forces you to pick the least important features and cut them rather than slipping into featuritis (a.k.a. scope creep).
Keeping schedules does not have to be hard. Read my article Painless Software Schedules, which describes a simple way to make great schedules.
这就引出了日程安排的问题。如果你的代码对企业至关重要，那么知道代码何时完成对企业而言非常重要，有很多原因。程序员在制定日程安排方面通常会很不情愿。“等它做好了再说！”他们对企业人员大喊大叫。
不幸的是，这样做是不够的。在发布代码之前，企业需要提前做出太多的计划决策：演示、交易展览、广告等等。唯一的方法就是有一个日程安排，并且保持更新。
拥有日程安排的另一个关键点是，它迫使你决定要做哪些功能，然后迫使你选择最不重要的功能并削减它们，而不是陷入“功能过剩”（也称为范围膨胀）的陷阱中。
制定日程安排并不难。请阅读我的文章《无痛软件日程安排》，描述了一种制定出色日程安排的简单方法。
Writing specs is like flossing: everybody agrees that it’s a good thing, but nobody does it.
I’m not sure why this is, but it’s probably because most programmers hate writing documents. As a result, when teams consisting solely of programmers attack a problem, they prefer to express their solution in code, rather than in documents. They would much rather dive in and write code than produce a spec first.
At the design stage, when you discover problems, you can fix them easily by editing a few lines of text. Once the code is written, the cost of fixing problems is dramatically higher, both emotionally (people hate to throw away code) and in terms of time, so there’s resistance to actually fixing the problems. Software that wasn’t built from a spec usually winds up badly designed and the schedule gets out of control. This seems to have been the problem at Netscape, where the first four versions grew into such a mess that management stupidly decided to throw out the code and start over. And then they made this mistake all over again with Mozilla, creating a monster that spun out of control and took several years to get to alpha stage.
My pet theory is that this problem can be fixed by teaching programmers to be less reluctant writers by sending them off to take an intensive course in writing. Another solution is to hire smart program managers who produce the written spec. In either case, you should enforce the simple rule “no code without spec”.
Learn all about writing specs by reading my 4-part series.
编写规格说明书就像使用牙线一样：大家都同意这是一件好事，但却没有人去做。
我不确定为什么会这样，但可能是因为大多数程序员讨厌编写文件。结果，当完全由程序员组成的团队解决一个问题时，他们更愿意用代码而不是文件来表达他们的解决方案。他们宁愿立即开始编写代码，而不是先制定规格说明书。
在设计阶段，当你发现问题时，通过编辑几行文本就可以轻松修复它们。一旦代码编写完毕，修复问题的成本将显著增加，无论是情感上（人们不喜欢扔掉代码）还是时间上，因此实际上会有抵制修复问题的倾向。没有从规格说明书开始构建的软件通常设计不良，日程安排也会失控。这似乎是Netscape的问题，前四个版本变得混乱不堪，管理层愚蠢地决定扔掉代码重新开始。然后他们在Mozilla上再次犯了这个错误，造成了一个失控的怪物，花了几年时间才达到alpha阶段。
我的个人理论是，通过让程序员参加密集的写作课程，可以解决这个问题，让他们变得不那么抵触写作。另一种解决方案是聘请聪明的程序管理人员来制定书面规格说明书。无论哪种情况，你都应该强制执行一个简单的规则：“没有规格说明书，不写代码”。
通过阅读我的四部曲系列文章，了解有关编写规格说明书的全部知识。
There are extensively documented productivity gains provided by giving knowledge workers space, quiet, and privacy. The classic software management book Peopleware documents these productivity benefits extensively.
Here’s the trouble. We all know that knowledge workers work best by getting into “flow”, also known as being “in the zone”, where they are fully concentrated on their work and fully tuned out of their environment. They lose track of time and produce great stuff through absolute concentration. This is when they get all of their productive work done. Writers, programmers, scientists, and even basketball players will tell you about being in the zone.
The trouble is, getting into “the zone” is not easy. When you try to measure it, it looks like it takes an average of 15 minutes to start working at maximum productivity. Sometimes, if you’re tired or have already done a lot of creative work that day, you just can’t get into the zone and you spend the rest of your work day fiddling around, reading the web, playing Tetris.
The other trouble is that it’s so easy to get knocked out of the zone. Noise, phone calls, going out for lunch, having to drive 5 minutes to Starbucks for coffee, and interruptions by coworkers — especially interruptions by coworkers — all knock you out of the zone. If a coworker asks you a question, causing a 1 minute interruption, but this knocks you out of the zone badly enough that it takes you half an hour to get productive again, your overall productivity is in serious trouble. If you’re in a noisy bullpen environment like the type that caffeinated dotcoms love to create, with marketing guys screaming on the phone next to programmers, your productivity will plunge as knowledge workers get interrupted time after time and never get into the zone.
With programmers, it’s especially hard. Productivity depends on being able to juggle a lot of little details in short term memory all at once. Any kind of interruption can cause these details to come crashing down. When you resume work, you can’t remember any of the details (like local variable names you were using, or where you were up to in implementing that search algorithm) and you have to keep looking these things up, which slows you down a lot until you get back up to speed.
Here’s the simple algebra. Let’s say (as the evidence seems to suggest) that if we interrupt a programmer, even for a minute, we’re really blowing away 15 minutes of productivity. For this example, lets put two programmers, Jeff and Mutt, in open cubicles next to each other in a standard Dilbert veal-fattening farm. Mutt can’t remember the name of the Unicode version of the strcpy function. He could look it up, which takes 30 seconds, or he could ask Jeff, which takes 15 seconds. Since he’s sitting right next to Jeff, he asks Jeff. Jeff gets distracted and loses 15 minutes of productivity (to save Mutt 15 seconds).
Now let’s move them into separate offices with walls and doors. Now when Mutt can’t remember the name of that function, he could look it up, which still takes 30 seconds, or he could ask Jeff, which now takes 45 seconds and involves standing up (not an easy task given the average physical fitness of programmers!). So he looks it up. So now Mutt loses 30 seconds of productivity, but we save 15 minutes for Jeff. Ahhh!
给知识工作者提供空间、宁静和隐私，可以显著提高生产力，这一点有大量的文献资料加以证明。经典的软件管理书籍《Peopleware》详细记录了这些生产力的益处。
然而问题在于，我们都知道知识工作者通过进入"状态"，也就是完全专注于工作并完全忽略环境的状态，才能发挥最佳效果。他们会完全沉浸其中，忘记时间，在高度集中注意力的情况下创作出优秀的作品。作家、程序员、科学家甚至篮球运动员都会告诉你他们进入了这种状态。
问题在于，进入"状态"并不容易。如果你试图对其加以衡量，你会发现平均需要15分钟才能达到最高生产力。有时候，如果你感到疲劳或者当天已经做了很多创造性的工作，你就无法进入状态，接下来的工作时间你只能四处摸索、上网阅读或者玩俄罗斯方块。
另一个问题是，很容易被打扰而打破状态。噪音、电话、外出吃午饭、开车5分钟去星巴克买咖啡以及同事的打扰，尤其是同事的打扰，都会打破你的状态。如果一个同事问了你一个问题，导致你被打断了1分钟，但这严重影响了你的状态，需要半个小时才能重新进入工作状态，那么你的整体生产力就会受到严重威胁。如果你在像咖啡因类互联网公司喜欢创建的嘈杂的开放式办公环境中，市场人员在程序员旁边大声讲电话，知识工作者一次次地被打断，永远无法进入状态，那么你的生产力将会大幅下降。
对于程序员来说，情况尤其困难。生产力取决于能够同时记住许多小细节的短期记忆。任何形式的打扰都可能导致这些细节全部遗忘。当你恢复工作时，你无法记住任何细节（比如你正在使用的局部变量名，或者你在实现搜索算法中的进度），你不得不一直查找这些信息，这会大大拖慢你的速度，直到你重新进入状态为止。
让我们来进行简单的代数计算。假设（据证据显示）如果我们打扰一个程序员，即使只是一分钟，实际上我们浪费了15分钟的生产力。举个例子，我们将两个程序员Jeff和Mutt放在标准的Dilbert狭小办公室中的相邻开放式小隔间里。Mutt忘记了strcpy函数的Unicode版本的名称。他可以查找，需要30秒，或者他可以问Jeff，只需要15秒。由于他就坐在Jeff旁边，他选择问Jeff。Jeff被打扰，损失了15分钟的生产力（为了节省Mutt的15秒）。
现在我们将他们分别安排在有墙壁和门的独立办公室里。现在，当Mutt忘记了那个函数的名称时，他可以查找，仍然需要30秒，或者他可以问Jeff，现在需要45秒，并需要站起来（考虑到程序员们平均身体素质不佳，这并不容易！）。所以他选择查找。现在Mutt损失了30秒的生产力，但我们为Jeff节省了15分钟。啊！
Writing code in a compiled language is one of the last things that still can’t be done instantly on a garden variety home computer. If your compilation process takes more than a few seconds, getting the latest and greatest computer is going to save you time. If compiling takes even 15 seconds, programmers will get bored while the compiler runs and switch over to reading The Onion, which will suck them in and kill hours of productivity.
Debugging GUI code with a single monitor system is painful if not impossible. If you’re writing GUI code, two monitors will make things much easier.
Most programmers eventually have to manipulate bitmaps for icons or toolbars, and most programmers don’t have a good bitmap editor available. Trying to use Microsoft Paint to manipulate bitmaps is a joke, but that’s what most programmers have to do.
At my last job, the system administrator kept sending me automated spam complaining that I was using more than … get this … 220 megabytes of hard drive space on the server. I pointed out that given the price of hard drives these days, the cost of this space was significantly less than the cost of the toilet paper I used. Spending even 10 minutes cleaning up my directory would be a fabulous waste of productivity.
Top notch development teams don’t torture their programmers. Even minor frustrations caused by using underpowered tools add up, making programmers grumpy and unhappy. And a grumpy programmer is an unproductive programmer.
To add to all this… programmers are easily bribed by giving them the coolest, latest stuff. This is a far cheaper way to get them to work for you than actually paying competitive salaries!
使用编译语言编写代码是目前在普通家用计算机上无法立即完成的最后一件事情之一。如果编译过程需要几秒钟以上的时间，购买最新最好的计算机将能够节省您的时间。如果编译时间甚至超过15秒，程序员们在编译运行期间会感到无聊，然后转而阅读《洋葱报》等内容，这将浪费数小时的生产力。
如果只有一个显示器的系统中调试GUI代码是非常困难甚至不可能的。如果您正在编写GUI代码，使用两个显示器会让事情变得更容易。
大多数程序员最终都需要处理位图以用于图标或工具栏，而且大多数程序员没有一个好的位图编辑器可用。试图使用微软画图工具来处理位图是一个笑话，但这却是大多数程序员必须做的事情。
在我上一份工作中，系统管理员不断给我发送自动垃圾邮件，抱怨我在服务器上使用了超过……注意，220兆字节的硬盘空间。我指出，考虑到现在硬盘的价格，这些空间的成本远远低于我使用的厕纸的成本。花费10分钟清理我的目录将是对生产力的巨大浪费。
顶级开发团队不会折磨他们的程序员。即使是由使用性能低下的工具引起的轻微挫折也会累积起来，让程序员变得暴躁和不开心。而一个暴躁的程序员是一个没有生产力的程序员。
除此之外，程序员很容易被提供最酷、最新的工具所贿赂。这比支付竞争力薪水更廉价地让他们为您工作！
If your team doesn’t have dedicated testers, at least one for every two or three programmers, you are either shipping buggy products, or you’re wasting money by having 30/hour testers. Skimping on testers is such an outrageous false economy that I’m simply blown away that more people don’t recognize it.
Read Top Five (Wrong) Reasons You Don’t Have Testers, an article I wrote about this subject.
如果您的团队没有专门的测试人员，每两到三名程序员至少需要一名测试人员，那么您要么在发布有缺陷的产品，要么就是浪费了以每小时100美元的程序员来做可以由每小时30美元的测试人员完成的工作。节省测试人员的开支是如此令人无法接受的错误经济学，以至于我简直难以理解为什么更多的人没有认识到这一点。
请阅读我写的一篇关于这个主题的文章《您没有测试人员的前五个（错误）原因》，以获取更多信息。
Would you hire a magician without asking them to show you some magic tricks? Of course not.
Would you hire a caterer for your wedding without tasting their food? I doubt it. (Unless it’s Aunt Marge, and she would hate you forever if you didn’t let her make her “famous” chopped liver cake).
Yet, every day, programmers are hired on the basis of an impressive resumé or because the interviewer enjoyed chatting with them. Or they are asked trivia questions (“what’s the difference between CreateDialog() and DialogBox()?”) which could be answered by looking at the documentation. You don’t care if they have memorized thousands of trivia about programming, you care if they are able to produce code. Or, even worse, they are asked “AHA!” questions: the kind of questions that seem easy when you know the answer, but if you don’t know the answer, they are impossible.
Please, just stop doing this. Do whatever you want during interviews, but make the candidate write some code. (For more advice, read my Guerrilla Guide to Interviewing.)
您会雇佣一个魔术师而不要求他们表演一些魔术吗？当然不会。
您会在婚礼上雇用一个餐饮服务商而不尝试他们的食物吗？我怀疑不会。（除非是玛姬阿姨，如果你不让她做她“出名”的切肝蛋糕，她会永远恨你）。
然而，每天，程序员被雇佣是基于令人印象深刻的简历，或者是因为面试官喜欢和他们聊天。或者他们被问些琐事问题（比如，“CreateDialog()和DialogBox()有什么区别？”），这些问题可以通过查看文档来回答。你不关心他们是否记住了成千上万关于编程的琐事，你关心的是他们能否编写代码。甚至更糟糕的是，他们被问一些“啊哈！”问题：这种问题在你知道答案时似乎很容易，但如果你不知道答案，它们就变得不可能。
请停止这样做。在面试过程中，无论你做什么，都让应聘者编写一些代码。（欲了解更多建议，请阅读我的《面试游击手指南》。）
A hallway usability test is where you grab the next person that passes by in the hallway and force them to try to use the code you just wrote. If you do this to five people, you will learn 95% of what there is to learn about usability problems in your code.
Good user interface design is not as hard as you would think, and it’s crucial if you want customers to love and buy your product. You can read my free online book on UI design, a short primer for programmers.
But the most important thing about user interfaces is that if you show your program to a handful of people, (in fact, five or six is enough) you will quickly discover the biggest problems people are having. Read Jakob Nielsen’s article explaining why. Even if your UI design skills are lacking, as long as you force yourself to do hallway usability tests, which cost nothing, your UI will be much, much better.
走廊式可用性测试是指在走廊上拦住经过的人，强迫他们尝试使用你刚写的代码。如果你对五个人进行这样的测试，你将了解到关于你的代码可用性问题的95%。
良好的用户界面设计并不像你想象的那么难，而且如果你希望顾客喜爱并购买你的产品，它是至关重要的。你可以阅读我免费在线的 UI 设计书，这是给程序员的简短入门指南。
但是有关用户界面最重要的一点是，如果你向几个人展示你的程序（实际上，五或六个人就足够了），你将很快发现人们遇到的最大问题。阅读雅各布·尼尔森（Jakob Nielsen）的文章，解释了其中的原因。即使你的 UI 设计技巧有所欠缺，只要你强迫自己进行走廊式可用性测试（而且这几乎没有成本），你的用户界面将会好得多，好得多。
Daily Builds Are Your Friend Painless Bug Tracking plainless software schedules
本文作者:Eric
本文链接:
版权声明:本博客所有文章除特别声明外，均采用 BY-NC-SA 许可协议。转载请注明出处！