My other major activity at TechEd was bug-hunting to make certain the Visual J# Developer Center could launch on time. So, now there are nine developer centers. People have asked about the missing one. All I can say is watch the URL: for changes to come in the next few weeks. Oh, and I agree with Marcie, the wireless was flaky -- especially when there were a lot of people there. At 1:00-2:00am, I agree with Duncan.

OK, Shawn -- stop reading at this point.

I should never have gone to TechEd, or D shouldn't have. One way or the other, we've become (insinuated ourselves) critical to the Developer Centers. D wrote the tool we're all using to edit the hierarchy, and I added a few lines here and there. I used it to build the above mentioned Developer Center, when all the other, earlier Developer Centers only used it for a fraction of their site. The VJ# came along. Politics happened. Deadlines changed. Deadlines approached. Bugs increased. People freaked. Kent flew off. It seems that despite our best attempts, only D & I know how to use the tool properly. People freaked, blaming the tool. D & I used Tuesday, and variable WiFi connections to connect to the bug database and our page tool (yes, the same version everyone else was insisting was buggy) and hammer down the bugs.

This got me thinking about software design. People frequently complain about this software package or that being poorly designed, or difficult to use, or flaky, or whatever. I'm not so convinced, except for Lotus Notes. I'm probably one of the more accepting users, I can live with Outlook's White Screen of Sedation (most days), I'm a horrid beta tester, as I skip past a lot of bugs, without posting them.

What am I trying to get to here? A couple of things, I guess. One is to try to design software for people (read Joel Spolsky semi-religiously), but the other is to take some of the design stuff with a grain of salt. One person's great design is another's beast. It's all your perspective. Some will love some apps, and hate others. The other is a problem some people have (my wife being one of them). If you hit an issue, do you park yourself on it, and try to solve it, or do you move on, figuring you can solve it later. I'm definitely the latter, but I'm seeing more and more people that are the former. If you hit a bug with a program, follow the old doctor's prescription, "Don't do that". Don't keep bashing your head across some insignificant problem when the fix may arrive after you do steps 3-7.

OK, so perhaps I didn't have a point, I'm just trying to stay up.

TTFN - Kent

[Listening to: Spirit of the Radio - Rosetta Stone]

OK, I remembered the point I was going to try to make. Don't always assume a problem is a bug. If I enter stupid criteria at Google (like "dog"), and it doesn't find what I'm looking for (something about Lassie), it's not Google's fault. Similarly, if you think there's some previously-undiscovered bug in a common class in the .NET Framework, odds are you may be using it improperly.

Hmmm, that sounds a little arrogant. What I'm trying to say is that (this is starting to read like an old Saturday Night Live sketch) don't always assume it's a bug -- it might be you.