I started the day yesterday by meeting a potential client - that would be #3 for my one-man company - and ended the day helping client #2 conduct a phone interview for more contractors. Both events were surprises, and the juxtaposition offered a really interesting perspective.

New laptop time. Time to muck about with the zillion little apps that were preinstalled. This article looks like a pretty useful set of tools to optimize Windows. I didn't realize the extent to which System Restore slowed things down.

I was just reading this article on the new Windows Vista's various improvements. It's a nice level of detail about a lot of different areas, but I was rather surprised to see that they're finally fixing a really, really basic flaw in how windows are drawn.

When a single-threaded window is busy, it won't redraw itself. This frequently results in a locked-up white rectangle with an hourglass. It's really quite ugly. I've learned complicated ways around this but this complexity is harder to explain, harder to test, and on some rare but significant occasions with cross-language development, just doesn't work.

I never thought I'd see the day. :)

Robert Martin recently posted an interesting blog entry on Never Being Blocked. The article's more interesting than the comments, except for my comments of course :), and it ties together not just Agile ideas but several other useful practices into a common pattern he calls Not Being Blocked. I think I see what he's saying, but I think it's part of an even larger pattern.

What are the common elements of these common agile practices:
test-driven development?

refactoring?

customer-directed goals?

pair programming?

continuous integration?

frequent small releases?

and these other practices he mentions, which aren't direct corollaries of Agile, and don't require Agile, but often do seem to come up at the same time, from the same people:

why prefer non-blocking source control?

why build it yourself instead of waiting for another team or version?

why build it freeform instead of with a heavy internal architecture?

why build a stub for an incomplete or unavailable system?

Constant. Incremental. Improvements.

I went to another meeting of the Kentucky .NET group last night. The food was free, the speaker really knew his stuff... but they weren't talking to me. I think this says more about what I'm looking for than about this group.

The speaker was Tim Huckaby, and the topic was smart clients. Much of the discussion was interesting. But I didn't learn anything I could use, which made the demonstrations of stuff I couldn't use... well, it made those demos rather less interesting.

Here's where I part ways with Mr. Huckaby: There's nothing wrong with Office apps, and I'm sure Microsoft wants to plug them as a significant upgrade, but it isn't a "smart client". Since Office needs to be installed, an Office-based application using VSTO is what I would call a "rich client". Some distinction needs to be made if we're going to get any value out of this smart client thing at all.

Well, I've finally moved CharlesHaws.com onto it's own shiny new web host.

It's been parked forever on a separate site that I also used for the Blooded Horse Sales online entry tool.

But I made a mistake last month. I changed something on my personal web site - installing this new Drupal tool - and a side effect broke the online entry tool. In two different places, so when I fixed one, I left another hidden one there.

So, I shut my personal site down for a few days in order to fix it. Now, I've completely split apart the personal web site and the other one. CharlesHaws.com is now on ICDsoft, which my wife has been on for a few years now, and it looks good. $100 for 2 years. Basic but well-implemented. No Java servlets on this one, but I can still use the other site for some Java testing. Python's on there and that might be useful. No telnet, alas. But the third-party tools I'm likely to use are getting better about not needing that.

At some point I might pick up a third site that supports .NET or Mono. Just to play with, you know? Round out the different techs. I suspect that down the line I'll need that to use as a back end for my .NET smart client tests.

I absolutely love Kathy Sierra's blog. In addition to an extraordinary skill at coming up with simple imagery to communicate her ideas, she also has great ideas!

Today's is micromanagement. The first image draws you in and states something we all kind of know and agree with: Micromanagement stifles independent thinking.

The impressive thing to me is her ability to make us realize that we're doing it. She has identified the "good" side of micromanagement to a T, the things people use to justify it.

Are you a micromanager?

Martin Fowler has updated his five year old essay, The New Methodology. It's always been a great article, and it's even better now. Plenty of useful links for those who haven't heard of Agile.

It kind of makes me want to write a slightly different essay, specifically targeted at IT buyers and users rather than IT developers. People who may or may not have heard the buzzwords and just want to know what this means to them. I'll be borrowing heavily from Fowler and others, of course. :)

So, I present my Guide to Buying Custom Business Software.

Someday I suppose I should assemble a set of pages that communicate what I do to prospective clients better than these pseudo-random discussions.

I'd like to think it would look a lot like this. Well done, Jim.

I approve of the way he avoids a bullet point list of skills and buzzwords. I don't do training, but I've always felt that the best description of my own work is "I solve information problems" rather than "I do C++, SQL, C#, OO theory, etc."

I've often wondered this. It's really not a very good format. But I've used it a couple of times, because it's easy and well supported. I didn't need to move data between two different systems that couldn't share a more direct interface, which is XML's unique strength.

Christopher Diggins, in about the tenth comment down on this post, has a very clear explanation for why. The rest of the article is interesting, but I'm focusing on one thing. I think that he's right about the reasons we use XML, but that suggests to me a potential path for change: