Month / November 2000

by Joel Spolsky

2000/11/12

Transmeta goes Public

I like Transmeta, for two big reasons.

First, they are the first CPU designers to finally admit that the age of designing instruction sets is over. If you want to design a CPU for PCs, and you want people to use it, you no longer have the luxury of inventing your own instruction set. You have to run x86 code. Period. And Transmeta recognized this from the start.

The second reason I like Transmeta is that they decided to tackle a really, really hard problem, even though it took many years to get launched. This is not a “build to flip” company. They don’t mind going after Intel, which is very brave of them. That puts them squarely in the Ben and Jerry’s camp. So many of the dot coms that are blowing up right now were built in about three months and never had any sustainable competitive advantage, let alone barriers to entry, and it’s no wonder that they’re doing so badly.

(By the way, when I say “I like Transmeta,” I don’t mean as an investment. Intel is probably going to squash them like a bug without even doing anything. Which is too bad, because I like Transmeta.)

Caution, the moving walk is nearing its end. Please watch your step.

I’m in Denver airport waiting for a flight back to NYC on the utterly, completely horrid United Airlines. As I look around dozens of flights are either cancelled, delayed by hours, or overbooked. The customer service line for rebooking is miles long.

If you know the secret, you can get a nice cubicle upstairs with an ethernet connection to the Internet ($3.95 for 30 minutes) and very comfortable aeron chairs. The only trouble is that it’s near the end of the moving walk, and there’s a voice on the loudspeakers which repeats, “caution, the moving walk is nearing its end. Please watch your step.” every half minute or so. So far it hasn’t driven me crazy, yet, but I’m sure it will.

Inprise is Borland Again

The only time a company would want to change its name, from something people recognize to something completely new, would be if it had such low brand equity that the old name was a liability. So ValuJet, nearly bankrupted due to their shockingly poor safety record, changed their name to AirTran, and when a bunch of consumer-loathed phone companies merged (Bell Atlantic, GTE, and AirTouch) they must have decided that not one of those names was worth the recognition, so they came up with Verizon. But there was nothing wrong with Borland, so I never understood why they changed their name to Inprise.

I guess they didn’t either, because looking at their web site, it seems like they’re back to Borland.

Prediction: you’ll see a lot of name changes among local phone companies, cable television companies, and airlines over the next few years, as the shakeout for years of abysmal customer service starts to catch up with them.

by Joel Spolsky

2000/11/09

Is Bush going to actually be the next president because of a usability bug?

picture-ballot:

“If your program model is nontrivial, it’s probably not the user model.” (from Chapter 2 of UI design for programmers) Any time you do something even a little bit complicated, some part of your user population is going to be confused, because they thought that you were doing the simple thing.

Obviously, usability matters for more than just web sites. Tog writes about this in When Interfaces Kill. And this Florida ballot is going to show up in UI books for the next 100 years.

Florida’s Web Site

The Florida Department of State web server is bogged down from zillions of people checking election results. State CIO Gene Bryan is quoted by CNN as saying, “There’s not a whole lot you can do other than just get through the night and try to regroup in the morning to get some additional resources to handle the workload.”

Um, hello? They’ve got 4 or five stupid GIFs and a gratuitous scrolling Java applet on that damn page. No wonder you can’t handle the load. Clue: Turn off the applet and GIFs for a couple of weeks. Duh. Any half-baked web developer would know that.

by Joel Spolsky

Painless Bug Tracking

TRS-80 Level-I BASIC could only store two string variables, A$ and B$. Similarly, I was born with only two bug-storing-slots in my brain. At any given time, I can only remember two bugs. If you ask me to remember three, one of them will fall on the floor and get swept under the bed with the dust bunnies, who will eat it.

Keeping a database of bugs is one of the hallmarks of a good software team. I never cease to be amazed at how few teams are actually doing this. One of the biggest incorrect facts that programmers consistently seem to believe is that they can remember all their bugs or keep them on post-it notes.

If I can bend your ear a moment, I’d like to explain a pretty painless way to do bug tracking, in the spirit of my previous articles on painless schedules and painless specs.

First of all, you need a real database. On teams of 2 people writing a little bit of code over the course of a long weekend, it’s probably OK to use a text file as the database. Anything larger, and you’re going to need a real bug tracking database. There are zillions of bug tracking databases you can buy. (Blatant self-promotion: the bug tracker we wrote at Fog Creek Software, called FogBugz, is web based, pretty easy to use, and quite powerful, if I may say so myself.)

Let’s follow a bug around, for the purpose of illustration, from the moment it’s born until someone finally puts it out of its misery. We’ll follow the famous Bug 1203. Here’s what the bug database shows for that bug:

ID   1203
Project   Bee Flogger 2.0 
Area   FTP Client
Title   Uploading file causes FTP server to dump core
Assigned To   CLOSED
Status   CLOSED (RESOLVED – FIXED)
Priority   2 – Must Fix
Fix For   2.0 Alpha
Version   Build 2019
Computer   Jill’s iMac, Mac OS 9.0, 128M RAM, 1024×768 millions of colors
Description   11/1/2000 Opened by Jill the Very, Very Good Tester

* Start Bee Flogger
* Create an unnamed document simply containing the letter “a”
* Click on the FTP button on the toolbar
* Try to ftp to your server

BUG: Observe; the ftp server is no longer responding. Indeed ps -augx shows that it is not even running and there is a core dump in /.

EXPECTED: No crash

11/1/2000 Assigned to Willie the Lead Developer by Jill the Very, Very Good Tester

11/2/2000 (Yesterday) RESOLVED – WON’T FIX by Willie the Lead Developer

Not our code, Jill, that’s just proftpd which comes with Linux.

11/2/2000 (Yesterday) Reactivated (assigned to Willie the Lead Developer) by Jill the Very, Very Good Tester

That doesn’t sound right. I’ve never been able to crash proftpd when I connect with a normal ftp client. Our code crashes it every single time. Ftp servers don’t just “crash”.

11/3/2000 (Today) Assigned to Mikey the Programmer by Willie the Lead Developer

Mikey, can you look at this? Maybe your client code is doing something wrong.

11/3/2000 (Today) RESOLVED – FIXED by Mikey the Programmer

I think I was passing the user name instead of the password or something…

11/3/2000 (Today) Reactivated (assigned to Mikey the Programmer) by Jill the Very, Very Good Tester

Still happens in Build 2021.

11/3/2000 (Today) Edited by Mikey the Programmer

Whoa. That’s strange. Lemme debug this.

11/3/2000 (Today) Edited by Mikey the Programmer

I’m thinking it might be MikeyStrCpy()…

11/3/2000 (Today) RESOLVED – FIXED by Mikey the Programmer

Ahhh!
FIXED!

11/3/2000 (Today) Closed by Jill the Very, Very Good Tester

Appears fixed in build 2022, so I’ll go ahead and close this.

Here’s what happened.

Mikey the Programmer is hacking away on the new FTP client feature of his groovy Macintosh software. At some point, because he’s feeling frisky, he writes his own string-copy function. That’ll teach them pesky reusability police! Bwa ha ha!

Bad things happen when you don’t reuse code, Mikey. And today, the bad thing that happened was that Mikey forgot to null-terminate the copied string. But he never noticed the problem because most of the time he happened to be copying strings into pre-zeroed memory.

Later that week, Jill the Very, Very Good Tester is banging away at the code, rolling her forehead back and forth on the keyboard or some equally cruel test.  (Incidentally, most good testers are named Jill, or some variation like Gillian.) Suddenly something very strange happens: the ftp daemon she was testing against crashed. Yes, I know it’s a Linux machine and Linux machines never crash (no snorting sounds from the slashdot crowd, please) but this dang thing crashed. And she wasn’t even touching the server, she was just FTPing files to it using Mikey’s Mac code.

Now, Jill is a very, very good tester, so she’s kept a careful log of what she was doing (the precise pitch and yaw of her head as she rolled it on the keyboard is in her lab book, for example). She reboots everything, starts with a clean machine, repeats the steps, and — Lo and Behold — it happens again! The Linux ftp daemon crashed again! That’s twice in one day, now! Take that, Linus.

Jill squints at the list of repro steps. There are about 20 steps. Some of them don’t seem related. After a bit of experimentation, Jill is able to whittle the problem down to four steps that always cause the same behavior. Now she’s ready to file a bug.

Jill enters the new bug in the bug tracking database. Now, just the act of entering a bug requires some discipline: there are good bug reports and bad bug reports.

Three Parts To Every Good Bug Report

And the Lord spake, saying, “First shalt thou take out the Holy Pin. Then, shalt thou count to three, no more, no less. Three shall be the number thou shalt count, and the number of the counting shalt be three. Four shalt thou not count, nor either count thou two, excepting that thou then proceed to three. Five is right out. Once the number three, being the third number, be reached, then lobbest thou thy Holy Hand Grenade of Antioch towards thou foe, who being naughty in my sight, shall snuff it.”

— Monty Python and the Holy Grail

It’s pretty easy to remember the rule for a good bug report. Every good bug report needs exactly three things.

  1. Steps to reproduce,
  2. What you expected to see, and
  3. What you saw instead.

Seems easy, right? Maybe not. As a programmer, people regularly assign me bugs where they left out one piece or another.

If you don’t tell me how to repro the bug, I probably will have no idea what you are talking about. “The program crashed and left a smelly turd-like object on the desk.” That’s nice, honey. I can’t do anything about it unless you tell me what you were doing. Now, I admit that there are two cases where it’s hard to get exact steps to repro. Sometimes you just don’t remember, or you’re just transcribing a bug from “the field.” (By the way, why do they call it “the field”? Is it, like, a field of rye or something? Anyway…) The other time it’s OK not to have repro steps is when the bug happens sometimes but not all the time, but you should still provide repro steps, with a little annotation that says that it doesn’t happen too often. In these cases, it’s going to be really hard to find the bug, but we can try.

If you don’t specify what you expected to see, I may not understand why this is a bug. The splash screen has blood on it. So what? I cut my fingers when I was coding it. What did you expect? Ah, you say that the spec required no blood! Now I understand why you consider this a bug.

Part three. What you saw instead. If you don’t tell me this, I don’t know what the bug is. That one is kind of obvious.

Back To Our Story

Anyhoo. Jill enters the bug. In a good bug tracking system it gets automatically assigned to the lead developer for that project. And therein lies the second concept: every bug needs to be assigned to exactly one person at all times, until it is closed. A bug is like a hot potato: when it’s assigned to you, you are responsible to resolve it, somehow, or assign it to someone else.

Willie, the lead developer, looks at the bug, decides it’s probably something to do with the ftp server, and resolves it as “won’t fix.” After all, they didn’t write the ftp server.

When a bug is resolved, it gets assigned back to the person who opened it. This is a crucial point. It does not go away just because a programmer thinks it should. The golden rule is that only the person who opened the bug can close the bug. The programmer can resolve the bug, meaning, “hey, I think this is done,” but to actually close the bug and get it off the books, the original person who opened it needs to confirm that it was actually fixed or agree that it shouldn’t be fixed for some reason.

Jill gets an email telling her that the bug is back in her court. She looks at it and reads Willie the Lead Developer’s comments. Something doesn’t sound right. People have been using this ftp server for years and it doesn’t crash. It only crashes when you use Mikey’s code. So Jill reactivates the bug explaining her position, and the bug goes back to Willie. This time Willie assigns the bug to Mikey to fix.

Mikey studies the bug, thinks long and hard, and completely misdiagnoses the bug. He fixes some altogether different bug, and then resolves the one Jill opened.

The bug is back to Jill, this time marked “RESOLVED-FIXED”. Jill tries her repro steps with the latest build, and, lo and behold, the Linux server crashes. She reactivates the bug again and assigns it straight back to Mikey.

Mikey is perplexed, but he finally tracks down the source of the bug. (Know what it is yet? I’ll leave it as an exercise to the reader. I’ve given you enough clues!) He fixes it, tests it, and — Eureka! The repro case no longer crashes the ftp server. Once again, he resolves it as FIXED. Jill also tries the repro steps, discovers that the bug is good ‘n’ fixed, and closes it out.

Top Ten Tips for Bug Tracking

  1. A good tester will always try to reduce the repro steps to the minimal steps to reproduce; this is extremely helpful for the programmer who has to find the bug.
  2. Remember that the only person who can close a bug is the person who opened it in the first place. Anyone can resolve it, but only the person who saw the bug can really be sure that what they saw is fixed.
  3. There are many ways to resolve a bug. FogBUGZ allows you to resolve a bug as fixed, won’t fix, postponed, not repro, duplicate, or by design.
  4. Not Repro means that nobody could ever reproduce the bug. Programmers often use this when the bug report is missing the repro steps.
  5. You’ll want to keep careful track of versions. Every build of the software that you give to testers should have a build ID number so that the poor tester doesn’t have to retest the bug on a version of the software where it wasn’t even supposed to be fixed.
  6. If you’re a programmer, and you’re having trouble getting testers to use the bug database, just don’t accept bug reports by any other method. If your testers are used to sending you email with bug reports, just bounce the emails back to them with a brief message: “please put this in the bug database. I can’t keep track of emails.”
  7. If you’re a tester, and you’re having trouble getting programmers to use the bug database, just don’t tell them about bugs – put them in the database and let the database email them.
  8. If you’re a programmer, and only some of your colleagues use the bug database, just start assigning them bugs in the database. Eventually they’ll get the hint.
  9. If you’re a manager, and nobody seems to be using the bug database that you installed at great expense, start assigning new features to people using bugs. A bug database is also a great “unimplemented feature” database, too.
  10. Avoid the temptation to add new fields to the bug database. Every month or so, somebody will come up with a great idea for a new field to put in the database. You get all kinds of clever ideas, for example, keeping track of the file where the bug was found; keeping track of what % of the time the bug is reproducible; keeping track of how many times the bug occurred; keeping track of which exact versions of which DLLs were installed on the machine where the bug happened. It’s very important not to give in to these ideas. If you do, your new bug entry screen will end up with a thousand fields that you need to supply, and nobody will want to input bug reports any more. For the bug database to work, everybody needs to use it, and if entering bugs “formally” is too much work, people will go around the bug database.

If you are developing code, even on a team of one, without an organized database listing all known bugs in the code, you are simply going to ship low quality code. On good software teams, not only is the bug database used universally, but people get into the habit of using the bug database to make their own “to-do” lists, they set their default page in their web browser to the list of bugs assigned to them, and they start wishing that they could assign bugs to the office manager to stock more Mountain Dew.

by Joel Spolsky

2000/11/07

Despite the hubbub over Phil Greenspun’s article about managing engineers, I still think the article is almost right. The best part of the article:

  • Phil says that you have to make an office environment that’s “nicer than most programmers’ homes” so that they want to spend more time at work. That idea works, but not for the reason Phil gave. It works because if you make a nice environment, the best programmers will want to work for you, not for your competitors who treat them like veal.

The biggest bug:

  • Phil thinks it’s great when people work 70 hour weeks. I think that’s a way to make a short term burnout company. It looked successful to Phil because it worked for arsDigita in its first year or two. But look at Netscape, a company that was famous for deathmarch after deathmarch, and for burning out individual programmers, and indeed for burning out the whole damn company.

More discussion on this topic.

UI Design for Programmers

Due to popular demand, the book is now available as a single, giant HTML page suitable for downloading, printing, and reading in the park.

New Toys Department(why else go into business for yourself?)

I got a new laptop computer. It’s an IBM Thinkpad X20. Truly a great, tiny laptop computer with a real keyboard and a real screen. (Dave, these are much better than Vaios, and more reliable, too.)

Most of the day, I keep it plugged into a docking station so that I can use a full size monitor. Fog Creek is all about flat screens; we all use Samsung 770TFT monitors. These monitors are the best monitors you’ve ever seen, everybody that has them sings hosannas all day long. So far I’ve bought 4 of them. They are truly amazing. The screen is 17″, about the same size as a 19″ CRT. It’s the only flat screen that runs at 1280×1024 that you can afford ($1300 most places).

The Election

I can’t help it, voting makes me extremely happy and proud in a deep way. Standing in line with a bunch of fellow citizens doing our civic duty almost makes me tear up. Democracy is something we take for granted, but… think of it from a historical point of view. They let me — a Jew — vote! For 2000 years that was unheard of. I can vote for fat old Representative Jerry Nadler, a wonderful man who marches proudly in every NYC gay pride parade, sweating like a pig, even though he looks like he’s about to keel over. I love him. I have sent Jerry something like 3 dozen letters over the years, and in every single case, his political position was totally in sync with mine. “Save the whales, Jerry,” I would write, and he would respond, “yes, in fact I sponsored that bill.” “Protect free speech,” I would write, and he would respond, “indeed I wrote the very bill you’re talking about.” I’m proud to be able to vote for Jerry Nadler and ecstatic that I have that right.

by Joel Spolsky

2000/11/04

On Certification of Programmers

Steve McConnell, who has written at least one really good book on software engineering, wrote another book last year, called After the Gold Rush. Steve is very concerned with the “professionalism” of software engineers and the quality of their skills. The most controversial part of the new book is his call for some kind of official, government-type certification of programmers. His company’s website is full of statements like: “When ‘Professional Software Engineer’ certification becomes available in Washington…” When, not if. Yikes.

Needless to say, he’s not winning many friends with that idea. I would have written an essay about it, but Tom DeMarco has already done it much better than I could have. “Whatever the merits of certification, it has always been a big hit among those who get to do the certifying,” he writes. “Certification is not something we implement for the benefit of the society but for the benefit of the certifiers.” Read his short article, it’s great, and then ask yourself this: Would 18-year-old Shawn Fanning, who wrote Napster and changed the world, have been certified?

Don’t Buy “After the Gold Rush.” It’s wrong.

The new Robert Jordan book is about to ship. Buy that instead.

by Joel Spolsky

2000/11/03

Discussion Groups

I’ve created a discussion group for this site. You don’t have to be a member to post!

Discussion topic number one is:

Bill Gates on Poverty

“Pacing the room, waving his hands, he conjures up an image of an African village that receives a computer.

“‘The mothers are going to walk right up to that computer and say, My children are dying, what can you do?’ Mr. Gates says. ‘They’re not going to sit there and like, browse eBay or something. What they want is for their children to live. They don’t want their children’s growth to be stunted. Do you really have to put in computers to figure that out?'”

–Bill Gates, quoted in today’s New York Times.

by Joel Spolsky

2000/11/02

Jakob Nielsen says that Flash is “99% bad.” I have to agree. Flash always reduces usability.

On the other hand, every time I read Jakob Nielsen, I get this feeling that he really doesn’t appreciate that usability is not the most important thing on earth. Sure, usability is important (I wrote a whole book about it). But it is simply not everyone’s number one priority, nor should it be. You get the feeling that if Mr Nielsen designed a singles bar, it would be well lit, clean, with giant menus printed in Arial 14 point, and you’d never have to wait to get a drink. But nobody would go there, they would all be at Coyote Ugly Saloon pouring beer on each other.