I Don't Dream of Jeannie... or Why I Hate Wizards 

I briefly mentioned this in an earlier post about Component Based programming... but I really don't like Wizards. Why? Aren't Wizards a great tool to speed up development? Don't you use Visual Studio .NET and love it because it provides RAD capabilities? (RAD being Rapid Application Development... not a slang word from the 80's that nobody uses anymore.) I like VS.NET a lot. I like RAD features. I really hate Wizards. Maybe its the type of programmer I am... I refered to a post ealier about who the typical C# programmer is... where Rick Spencer found the following:

When we talk about "code focused" this meant a couple of things to us. First, the users we watched were very persnickety about their code. For example, they would spend a lot of time formatting their code the way they wanted. They would write a block of code, and then go back and indent it the way they wanted. They would copy code from somewhere, and then format it in their editor before they even read it. There just seems to be a sense that the code itself can be beautiful, and code that was ugly, and here I mean was formatted in the wrong way, was fixed up.

Wizards write ugly code. Its impersonal... its not formatted the way I want it. It uses variable names like "i" and "pI" and such. Have you ever tried to edit Wizard code? You end up renaming everything just so you can make heads or tails of it... which ends up taking you longer then had you started from scratch. Not only that, but Wizards write code for 75% of cases... but my cases always seem to fit in the 25% the Wizards don't cover. They never seem to ask the questions that I needed them to ask.

But Nick you say... what about the times when you never plan on editing the Wizard code? The Wizard code that gets written is perfect. Are you sure? How do you know? Have you looked at the Wizard code? Do you know what the Wizard did for you? Most people who say they've never edited Wizard code don't even know what the Wizard did for them... and thats dangerous in my mind. You should always know what a tool is doing for you. What happens if you need to undo something a Wizard did? Do you even know where to look for the code the Wizard wrote?

I was able to take a week long class a couple years ago taught by Doug Boling... who is the guru of Windows CE programming and author of Programming Windows CE. He talked about when he would interview people who said that they were experts on MFC... he would ask them one question, which he asked us. How does MFC work? (Think about it for a while and I'll tell you the answer I gave Boling at the end of the post). Invariably people he interviewed would talk about starting the New Application Wizard and choosing this or that, and boom you have an application. So for example if you are writing an Air Traffic Control Application... do you look for the New Air Traffic Control Application wizard and go from there. Select the number of runways, click Next. Choose the size of the airspace that you will cover, click Next. Accck!

When I was interviewing for a new job last year... the interviewer asked me what seemed to be an overly simple question. You have a COM interface that you want to add a method to. How do you do it? Of course being the good COM programmer I said... you don't. He raised an eyebrow. Published COM interfaces should NEVER be changed... thats one of biggest rules in COM! You create a new interface that inherits from the old one. Fine... its not published yet, how do you do it? I thought... this is too easy, its got to be a trick question. Well... you write the IDL for the new method, then implement the method in the class that implements the interface... right? What am I missing here? Of course that was correct, and he just wanted to make sure I didn't say... run the Add Method Wizard. Why? Because the damn Wizard hardly ever worked! Of course they ended up giving me some computer test from some website where half the questions talked about running this Wizard or that... and I was screwed.

So if you're going to use a Wizard despite all I've said... fine. I just ask one simple thing. Know what the Wizard does. Look at the code. Understand the code it wrote. Even if the Wizard wrote it, its still yours. If there's a bug because of it, your boss isn't going to care that a Wizard wrote it, not you. And if you can, go one step further. Edit the Wizard code. Add meaningful comments to the code (which Wizards never do... which is yet another reason I hate them). Rename some variables so the next guy reading your code will understand what the Wizard did. So thats enough for today's rant.

Oh yeah... and the answer to Boling's question (which he thought was right on by the way)...

while ( GetMessage( &msg, NULL, 0, 0 ) )
{
   TranslateMessage( &msg );
   DispatchMessage( &msg );
}

Even MFC programmers should read Petzold.