James Grimmelmann, Microsoft

James Grimmelmann is a resident of Seattle, Wash., a software design engineer with the Microsoft Corporation, and the madman behind The Laboratorium.

Software development is a resource-obsessed business, even though these "resources" are close to pure abstractions. Everything is measured in terms of its costs: how many CPU cycles this algorithm will take to run, how much disk space the program requires, can I do this search-and-replace with two passes over the list, or will I need three? It's typically pretty easy to write something that works; it tends to be much harder to write something that works without excessive waste of time and memory. We do everything we can to make sure we do things right the first time, but because we're mortal, we also schedule plenty of time for debugging.

It's debugging season here in my group, that slow and arduous march through waist-deep mud that every software project must engage in. We had a round of writing new code at the end of the summer, and now we have to clean up after ourselves and kill off as many of the bugs we introduced as we can.

Strangely enough, the more catastrophic the failure, the easier it can be to figure out what's going wrong. Something like dereferencing a null pointer (the software equivalent of trying to walk through a nonexistent door) sets off so many internal alarms in your program that you have some fairly specific evidence to start from. When a supertanker runs aground, at least you know where the problem is and where to work on dealing with it.

On the other hand, there are the memory leaks.

Imagine that you needed to store everything you owned in identical unmarked boxes, and that the only way to keep track of the contents of more than the few you can remember offhand is to keep lists of box contents in other boxes. This is the situation faced by a computer program storing things in memory. It's dangerously easy to have two boxes, each of which says "HANG ONTO THE STUFF IN THAT OTHER BOX," but no useful information as to what those two boxes were helping you keep track of. The program can't afford to take the risk of throwing out a box unless it knows that it's absolutely safe to do so; the space taken up by an unneeded box has "leaked" out of the system.

Specifically, I'm working on editing expense reports, employee reviews, shopping lists, and things like that. When I open up our sample expense report, and add an expense, the program uses 100 kilobytes more memory, which is fine, since it's presumably using that memory to keep track of the new expense item. But if I delete this new expense, the program is still using about 30 kilobytes more than when it started. If I add another expense and delete it, memory usage is up by 60 kilobytes. Three times means 90 kilobytes lost, and so forth.

This is no good; if the program runs for long enough, it will eventually start to choke on its own wastes, as it were. The computer will run out of memory and slow down to a crawl, even though very little of the memory is really being used. So I'm going through with a fine-toothed comb, trying to figure out which of the program's detritus it's forgetting to take out to the virtual curb for recycling.

Basically, I'm trying to leave behind enough explicit instructions -- e.g. things of the form

if (numberOfDaysSince(today, k_December25) >= 10)
      {
      pChristmasTree->Release();
      }

-- to make sure that we're not hanging onto stuff past its useful life. This can be a tricky business, because if a program allocates a million objects and releases all but 1,000 of them, just figuring out which 1,000 it's still hanging on to is a tricky task. Figuring out which 10 of these 1,000 it doesn't really need is even harder.

It's complex bookkeeping, and tiring, detail-oriented work, but it's also quite necessary. Especially for things like the software that powers major websites -- and doubly especially for the sections that get run millions of times in a day -- even a tiny memory leak can be fatal. Multiplied ever the course of a few days, losing even a few bytes every now and then rapidly adds up. Software has to live within its means, and unless it cleans up after itself, a program is quite capable of running its virtual ecology into the ground.