There's more, but I think you get the idea. There's lots of designer tools. Using some of these I find that:

They complicate matters beyond the prescribed use cases

(ie all of the tech demo videos)

I have been evaluating some of these technologies recently, and trying to work with them I end up having to dissect exactly what the designers, modellers and wizards are doing for me... otherwise I'm lost when I actually have to try to do something with whatever was created.

This ends up being a case where I have to fight the tool, or fight its output enough such that I could have just done the whole thing myself without it - and had a much stronger understanding of what's going on. I find this particularly infuriating with the silverlight designer and RIA services domain service wizard.

I find myself asking "What good is this tool if I have to figure out its inner workings or re-write half of its output in order to use it?"

They're not as fast

The selling point of these tools is to increase productivity and this point may change over time using the tool, and doesn't necessarily apply to UI designers (though, in some cases it still does -> I'm looking at you silverlight designer). I find that I can hack some code much faster than I can drag-and-drop, resize, move, whatever in a designer.

The UI gets in the way of the model

Maybe this is just me, but when I am using anything reminiscent of a UML design tool I end up spending more time laying everything out so that my lines don't cross and so that I can see it all on the screen than modelling what I'm trying to achieve.

They're no fun

Half of the reason that I code for a living is that I enjoy it. Clicking checkboxes and selecting comboboxes and then fixing everything that comes out isn't fun.

I don't appear to be alone

The community seems to not want these tools either. The best example I can think of at the moment is Entity Framework Code-First.

So I ask:

Do designer tools actually improve productivity?

Are they fun-killers?

Is 'the community' actually asking for more designer tools, or are vendors just thinking we are?

+1 I definitely like "yet to come across a good design tool". although I might have added "better than the gray matter between my eyeballs."
–
Ken HendersonDec 18 '10 at 3:16

2

+1 Wizards are only useful as long as what you're doing fits the model they embody. Because I mostly get paid to do weird things, they usually just get in the way. The only design tool like that I've ever really liked was (get ready for a shock from this Microsoft-non-fan) the graphical database and query generator in MS Access. It worked well because relational databases and SQL are both conceptually pretty simple and well-defined, so the design tool could handle almost anything you'd ever want to do.
–
Bob MurphyDec 18 '10 at 4:03

Anything you build yourself to help you with a task is a "good design tool". This includes your editor, your compiler, your debugger, your personal libraries, etc. The problem with most "payware" is that it has to be general enough for everybody, so it usually doesn't fit the problem well. And, they never bother to make it play nice! Follow the Unix philosophy please. I don't want to be in the MS' walled garden toolkit.
–
Spencer RathbunJan 27 '12 at 14:43

I think it probably depends. If you are a fairly inexperienced developer then using the design tools probably is more productive than typing it out. I'm fairly certain that I was more productive in my early VB6 days using the designer than I would have been cranking it out by hand. The other thing to consider is how does the technology (at least how the IDE presents it) lend itself to hand editing. VB6 and .NET WinForms certainly don't (or rather you probably don't want to hand edit the "generated" code file (or portion of). With WPF and ASP.NET I think that a fairly inexperienced developer will start with the designer but quickly graduate to editing the XAML/ASP directly. Once you know what you are doing it's certainly faster to edit the markup directly. Thinking back to EF v1.0, I had to edit the XML backing the designer and it sucked, I never could wrap my brain around it so I kept falling back to the designer.

Depends on if the markup is fun to work with. WPF and ASP(.NET) can be fun. VB6/WinForms - nope don't want to edit the generated code sections more than necessary.

I don't think the community does explicitly. Although when learning something new the designer can make it easier to swallow in chunks of learning.

From the vendor perspective, all those fancy designer tools seem to serve a purpose similar to discount/free student licenses. The idea is to allow you to create something with minimal effort and cost. Once you're invested, they're betting that you'll learn to expand your skills with their tools rather than go learn someone else's.

That's not to say the tools don't have legitimate productive uses. It should be valuable to examine generated code and learn from it. Unfortunately as Ken Henderson noted, the code is often unreadable and not something you want to use as a template for future work. I'm reminded of several sections in Programming WCF Services, where the author explains how to write code manually or have it generated by Visual Studio. Inevitably, the generated option requires a followup section for removal of extraneous code.

Its always been the way, even back in the day we used to distinguish between developers who only knew how to click the wizards, and developers who knew what code the wizards generated and could modify it for the edge cases.

That you've got even more tools, wizards, and designers all doing stuff under the covers to keep you from cutting yourself on the sharp bits is a benefit to developers who either don't want to know, or don't have the breadth of experience or skill to understand the generated code. I imagine there's a sweet spot between what you want the computer to do for you, and what you need to do yourself as the alternative is programming languages entirely based on dragging and dropping blocks onto a form. (I used to worked on just such a thing a domain-specific environment, I wouldn't want to use it!)