Coding Horror

I'm not a big screensaver enthusiast per se, but one of my all time favorite screensavers is definitely Moire from the DirectX 8.1 SDK. It's simple yet visually striking, and it works seamlessly on multiple monitors. It's also hardware accelerated on each monitor without requiring a lot of video card horsepower or CPU time.

One thing that always bugged me about Moire, though, was that it chose the same colors over and over. Every time it ran, it would cycle through the same exact color sequences, in the same order.

Well, after digging around (a lot) to find the DX 8.1 SDK that this sample is specific to, I came up with the C++ source for Moire. With the assistance of a coworker more versed in C++ than I, we managed to bundle Moire into a VS.NET 2003 C++ solution. Then I was able to hack in a more sophisticated random color algorithm with my completely negligible C++ coding skillz.

This solution compiles fine on any machine with VS.NET 2003 installed; no DirectX SDK is required. I've attached both the original, unmodified Moire from the SDK and our modified random color version. And if you don't feel like hacking on the source code, I put a binary up as well.

• Moire screensaver binary (173kb)
• Original Moire VS.NET 2003 C++ solution (70kb)
• Modified Moire VS.NET 2003 C++ solution (71kb)

In Waltzing with Bears: Managing Risk on Software Projects, DeMarco and Lister outline the dangers of penalizing negative thinking:

Once you've identified and quantified these risks, they can be managed just like the others. But getting them out on the table can be a problem. The culture of our organizations sometimes makes it impossible to talk about a really worrisome risk. We are like a primitive tribe that tries to hold the devil at bay by refusing to say his name.

Why didn't [technicians present at the 1986 Challenger launch] speak up [about the known risks of launching the shuttle in subzero weather conditions]? Their reasons were the same ones that stop people from articulating risks at companies everywhere. They take the form of unwritten rules, built into the corporate culture:

1. Don't be a negative thinker.
2. Don't raise a problem unless you have a solution for it.
3. Don't say something is a problem unless you can prove it is.
4. Don't be the spoiler.
5. Don't articulate a problem unless you want its immediate solution to become your responsibility

Healthy cultures attach great value to the concept of a team. Being judged a "team player" is enormously important, and not being one can be fatal to a career. Articulating a risk shouldn't be seen as anti-team, but it often is. These unwritten rules are not very discriminating; they don't make much distinction between speaking up responsibility and whining. And because they rules are never openly discussed, they never get adjusted for changing circumstances.

We are all enjoined to adopt a can-do mentality in our work. And there's the rub. Saying the risk is an exercise in can't-do. Risk discovery is profoundly at odds with this fundamental aspect of our organizations.

Waltzing with Bears is very clear on this point: the biggest risk on any software project is the risks you haven't considered. You can't know the unknown, of course, but you'll do a lot better at risk management if you encourage a culture of responsible risk assessment instead of mindless can-do heroics.

Personally, I love it when developers come to me with potential problems in our applications. Far from being negative, this has all kinds of positive implications:

• Deep knowledge of the application. The developer knows enough about the entire app to feel confident there's a problem.
• Concern for quality of workmanship. A less concerned developer would shrug this off as "not their problem". They get paid either way, right?
• Team player. If a developer is bringing up problems in a proactive way, that means they also (consciously or not) understand why it's important for the entire team to not fall prey to the Broken Window syndrome.

The only way to truly manage risk on a software development project is to solicit input from every team member on what could go wrong-- not only at the start of the project but also throughout its lifecycle. If you do, you'll have a far more predictable development schedule. And a much better product.

The Top 8 reasons user interface design is in the stone age is more of a rant than a reasoned argument, but it's still worth reading. If UI design is in the stone age, why are there at least two sites which document known UI patterns?

1. UI Patterns and Techniques (soon to be a book)
2. Web/Gui/Mobile Design patterns

I think we've come a long way from the stone age-- particularly after sitting through some very impressive demos of the Windows Vista and Office 12 UIs at PDC 2005 today. But it's true that there's still much to be done.

I was struck by how aggressively Microsoft has folded web metaphors into Vista and Office-- things like the forward and back buttons, focusing on a single task per page, and the ubiquitous search box. I've talked about this before, and I'm glad to see Microsoft leading the way.

Speaking of Vista, Flowstate is a great UI blog from an ex-UI architect for Windows Vista. Prior to Vista, he worked on Money-- one of the first inductive user interfaces. Subscribed!

Marcus Ranum, the inventor of the proxy firewall, brilliantly condenses why many security efforts are doomed from the start: they fall prey to the The Six Dumbest Ideas in Computer Security :

1. Default Permit
   Also known as "on by default". This one is huge, and it alone is why the phrase "Windows security" was such an oxymoron for so long. The good news is that Microsoft's new policy of "off by default" that kicked off with Windows Server 2003 is really working.
2. Enumerating Badness
   This is why blacklists are, and always will be, a bad idea. They're OK in helper roles for spot fixes, but as a primary means of defense, they are fatally flawed.
3. Penetrate and Patch
   Security starts from the inside, not the outside. No amount of patching will fix a fundamentally bad security design. Should you be patching-- or rearchitecting?
4. Hacking is Cool
   It is interesting that society considers spammers "sleazy con artists" yet hackers are "whiz kids". I think it has a lot to do with the financial motivations behind the crime. Maybe as hacking becomes more strongly associated with flat-out stealing, this will change.
5. Educating Users
   A security system that fails to assume users are fallible and weak by default is destined to fail spectacularly. Education, at least when used as security spackle, doesn't work.
6. Action is Better than Inaction
   You can always recognize the pioneers from all the arrows in their backs. Progress is good, but careful progress is even better. Always do your homework before jumping on any bandwagon.

That's the condensed Reader's Digest version, but I highly recommend reading the rest of the article.

While we're on the topic of security, TristanK has an interesting rant on keyloggers. I think it's a myth that you can protect yourself from the client PC anyway-- the client is always suspect. That is, until client PCs start looking a lot more like Xbox 360, where you have to solder a modchip on the motherboard to run custom software.

Courtesy of my employer, I have the privilege of attending this year's Professional Developers Conference.

I've been to a few trade shows, but this is the first technical conference I've ever attended. I arrive Monday night, and I'm definitely looking forward to it. Particularly since the watershed release of VS.NET 2005 and SQL Server 2005 is literally right around the corner. And this is the magical third version of a Microsoft product -- heady times indeed!

In addition to the precipitous timing, this year's PDC is doubly sweet because Jim Allchin's Tuesday keynote will cover something we've been working on here at Vertigo!

Aw, who am I kidding. I'm only there for the chicks. Or the guys named Steve. Or Brian.

I'm selecting sessions solely based on blogs I enjoy with no regard whatsoever for topic. I was surprised how few names in the session list I actually recognized; I guess I expected every presenter to be a blogger. But it does mean that I'll be seeing you, Panopticon Central, and you, Virtual PC Guy, and you, Mr. Performance Tidbits. And perhaps I'll cap it all off with the brothers Sells. I've also been told that The Microsoft Experience is not to be missed, so I'll be there too.

If anyone's looking for me at the PDC, just keep an eye out for a mildly overweight middle-aged white guy wearing glasses. I'll try to wear my .NET polo shirt so I really stand out.