Charles Petzold

Many years ago — about the time that visual design tools were being introduced into our programming environments — I promised that I would never believe myself to be teaching programming if I were writing sentences like "Now drag the Button from the toolbox to the window." I am proud to say I have kept to that promise.

Let me make this clear: As a programmer, I am not opposed to the use of visual design tools. But as a teacher of programming, I consider visual designers to be pedagogical catastrophes. Obviously they can't be used to teach good ways to construct code, and the reliance upon these tools by beginning progammers often leads to very sloppy and sometimes horrifying results.

An extreme example was provided by some recent email I received. A programmer writing a Windows Forms application needed to construct C# statements in strings during runtime and then execute these statements. I was curious why, because this is not a need that comes up very frequently in most programming jobs. Well, it seems he had a bunch of Label controls on his form, and they all had different names, and he couldn't find a way to access a particular one. But he was able to patch together strings such as "label800.Text = \"xyz\";" to do what he wanted, and that's why he needed a way to execute that statement at runtime.

It took me awhle to realize that the existence of controls with names such as label800 implied that he had laboriously constructed the visuals of his program by dragging over 800 Label controls from the Visual Studio toolbox to his form, and then arranging them into rows and columns.

Although there are many correct ways to solve any particular programming problem, there are also many totally wrong ways, and using a visual designer to create more than (say) half a dozen of the same type of control arranged in some kind of visual pattern of rows and columns is wrong, wrong, wrong, wrong, wrong. This is a job for code. The controls should be created in a for loop that algorithmically calculates their locations (if necessary), and then stores them in arrays for easy access. (The question whether over 800 Label statements is too many for one window is an issue I won't address at the moment.)

But why would anyone think these controls should be created through the visual designer? Well, bring up Visual Studio and create a new Windows Forms project. The screen that comes up is a design view, immediately encouraging you to drag and drop controls on the window's surface. Visual Studio is telling us that this is the proper way to design our program's visuals.

Not only Visual Studio, but many books and presentations encourage the use of visual design tools as well. I suppose the intent is to show how "easy" it is to build a new program. But that's clearly dishonest, and downright lazy on the teacher's part. Much more useful and valuable would be different varieties of code-based solutions. But when was the last time you saw a presentation where the instructor showed how to create controls in a for loop and store them in an array?

Of course, the problem has become worse with WPF and Silverlight. My original fear — that many programmers wouldn't learn how to do something in code that could be done in markup — has certainly become true, but now many programmers don't even write their own markup! Expression Blend has convinced many programmers that they don't need to learn how to write gradient brushes, or animations, or templates, or become familiar with the Visual State Manager because Expression Blend handles all that.

It sure does, and I'm probably not the only consultant who has seen horrifying pages of XAML animations generated by Expression Blend when a simple code-based solution (such as a custom panel) would work much better, and be easier to understand and maintain.

Obviously our programming tools partially determine the quality of the programs we write. This is why the GOTO was considered harmful and why it's been largely banished from modern programming languages. Innocent in itself, the GOTO nevertheless encouraged programmers to create big ugly mounds of steaming spaghetti code that no human could possibly navigate or interpret.

Now we get mounds of ugly markup that's not even formatted in a way to make it easy to read. We're not supposed to read it. We're supposed to trust Expression Blend. But Expression Blend won't tell us if there's a better way to do the job.

I don't know what the solution is. Certainly our programming environments should encourage us to actually write code or markup rather than to drag and drop controls. Visual design tools should be considered "advanced" techniques that programmers are qualified to use only when they can accurately predict what code or markup the visual designer is generating.

And certainly authors and presenters shouldn't pepper their introductions to WPF or Silverlight programming topics with sessions in Expression Blend. That's just plain irresponsible.