Do designer tools degrade the programming experience?

Question

I've been looking around lately, specifically at some of the MS tools that are available, and I'm noticing a big focus on designer tools and wizards. Not just for UI development but for everything.

• Entity Framework has the modeller
• RIA Services has the DomainService wizard(s)
• Workflow has the whole workflow designer thingy... (I don't know, haven't really used it)

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:

1. Do designer tools actually improve productivity?
2. Are they fun-killers?
3. Is 'the community' actually asking for more designer tools, or are vendors just thinking we are?

Answer 1

My guess is that good design tools do improve productivity and don't take away from "fun". However, it's only a guess because I have yet to come across a good design tool.

I personally have not asked for design tools.

Answer 2

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.

Answer 3

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!)

Answer 4

as usual, it depends

When I first investigated using web services, Java had a 50-page tutorial and .NET had a wizard. Guess which one got used?

Answer 5

Same here, no design tool.

I design the database ERD on paper, and write a deployer that issues the "create table" statements, that way I can wipe and rebuild at will. Also helps for database versioning.

I find that 11x17 (A3) paper can be a great place to design very compelex systems. Get a good eraser and pencils (I prefer Staedtler).

Answer 6

Do designer tools actually improve productivity?

They may as long as your project is simple and not too complex for them. My experience you hit the wall as soon you try to implement/solve a real world problem.

Are they fun-killers?

WF (Workflow) & WPF where fun but also killer when the VS 2008 crashed every 30min.

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

Many of tools released by MS lately seem to be desperate attempts to keep the developers. The battle is now going on in smart phone market. Who will win the hart of developers, MS, Google or Apple?

Answer 7

1. 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.

2. 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.

3. 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.