About 200 attendees came in Seattle; this will be one of our biggest scheduled demos except, maybe, London. I apologize that the screen wasn’t so easy to read throughout the room. We made a point of asking the hotel before we booked the room if the screen would be clearly visible to all attendees. It wasn’t, because the ceiling wasn’t high enough, and the hotel didn’t have the ability to raise the ceilings, so of course they lied and told us it would be fine, and it wasn’t. This is a problem at every tech conference I’ve ever been to; these rooms were built long before PowerPoint.

A bunch of Microsoftees had to cancel because they are having their annual company meeting today in a gigantic football stadium. The size of that company is insane. Can you imagine Safeco Field filled to the brim with software developers? And that’s just the Vista Shutdown Menu Team.

Something that came up in the demo today that I wanted to share. Software development is a cycle with three distinct phases: design, development, and debugging. It doesn’t really matter whether you’re doing Ultra Extreme Elite Programming, in which case you do all three phases in one week, or The Ancient OS/360 Waterfall Method, in which case you do them over the course of a year or two. You still have to design what you’re going to build, build it, and then debug it.

The three phases have to be scheduled in a very different way.

• Design is the art phase, where you’re doing new, creative work. Even though what you’re doing is completely new, after you’ve gone through a few software development cycles you’ll start to get a pretty good idea of how much time it takes to design a new version of your software. I’ve usually worked with relatively long development cycles of 12-18 months, and it’s always taken me about two months to get a detailed, first-draft spec containing enough detail for the development team to create very granular estimates.

  That said, when you’re building something brand new from scratch, you really can’t estimate the design phase at all, and that’s OK. Today I met somebody from a company in Seattle that’s working on a project headed up by one of the world’s great programmers, Charles Simonyi. Near as I can tell, they have been in the design phase for 16 years.

• Development is the engineering phase. It’s a construction project. As long as you start with a detailed blueprint, which, of course, can change over time, but which is really your best guess for what you’re building, this phase can be scheduled with great precision. FogBugz 6.0 has a spiffy new feature called Evidence-based scheduling, which uses a variation on the Monte Carlo method for making your schedules remarkably reliable during the development phase. When I get a chance, I’ll you about it in more detail.

• Debugging is the science phase. Science is difficult to schedule because you’re looking for things, and predicting when you’re going to find them is remarkably difficult. Unless you know in advance how many bugs you’re going to find, you don’t have an ice cube’s chance in the Sahara to work out a detailed estimate of how long this phase will take. Here at Fog Creek we’ve learned that for a new release of FogBugz, this phase takes at least 12 weeks, sometimes a little more, and we just leave it at that.

  Some people are more ambitious and try to track the rate at which bugs are being found and being fixed, and try to extrapolate to see when you’ll ship; in practice I’ve found that the rate of finding bugs is way too messy to be able to extrapolate from. If you have a fixed size test team and infinite bugs, they’ll find bugs at a constant rate, simply because they’re all spending 8 hours a day entering bugs and then stopping, but this flat line doesn’t mean you’re ever going to ship. You’re not. You have infinite bugs, remember? Sorry. On the other hand you may have just released a new beta to a new batch of beta testers, and it’s the best beta yet, but it’s the biggest group of beta testers, so there will be a big spurt of new bugs found, which doesn’t mean the code is getting buggier—it just means you have a bigger group of beta testers.

Now, there are various ways to get in trouble. If you don’t like writing functional specifications or doing up-front design, what happens is that you’re burdening the design phase with the development phase. If you ever started a new project by writing code, and you thought you’d “design as you went along,” what you’re doing is driving around with the handbrakes on. Here’s why. Designing a feature by writing a thoughtful spec takes about 1/10th as much time as writing the code for that feature—or less. If you try to code as you design, then you’re interrupting your short spurts of design with long spurts of coding. Now, if you’re the kind of person who designs everything perfectly the first time, that’s fine. But I don’t think you are. I think that your first designs are pretty good, but when you see them, you get ideas for even better designs. And if you already coded up the first draft, bad design, well, that’s coding time wasted. Your product’s design can only get better at 1/10th the speed that my product’s design can.

I’m now en-route to Chicago, where I have to do two speeches tomorrow: the morning FogBugz demo, and, in the afternoon, I’ll be talking about hiring to a bunch of startup CEOs at the Inc. 500 conference. I’m editing this in the e text editor, a Windows clone of TextMate, which is coming along nicely but could still use some polish before I’m ready to switch to it full time.