Inner Drive Software

My project manager sent around this link to Joel Spolsky's rules for software management:

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. 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.

I totally agree with Spolsky's list. I have never been on a project that scored better than 7 until now (which scores 9, IMO, but we're moving toward 11), and only one, ever, has answered "yes" to #8 (quiet working conditions).

We spent two hours yesterday debugging some code that kept firing early. It wasn't clear to anyone, including the people who wrote it, why this happened. We patched it with the C# equivalent of duck tape, but really, it still doesn't work right.

This incident shows how important it is to know what your code is supposed to do, and not to accept the code if it doesn't. Many tools exist to help—most notably, unit-testing tools like NUnit—but they have trouble with the specific problem that we encountered: events fired from black-box controls.

I will have more to say about this later.

I mentioned Friday that I've completely refactored the section of the Inner Drive Extensible Architecture™—the Idea™—that handles quantitative functions. (I've also decided to make some SDK documentation available.) The actual design of the IMeasurable classes—Length, Speed and the like—bears more discussion.