Are Designers, Wizards, etc. inherently Bad?

time to read 3 min | 592 words

Jdn has a good post that I recommend that you read about Novices, Sheep and Morts.

My feeling about designers, etc is that they are most certainly no inherently bad, they can be extremely valuable to get me someplace quickly. I do think that a lot of the designers, etc in use today are bad, because they produce unmaintainable code. Hell, WCF proxy generator is a good example of one, it doesn't recognize the common binding settings, always producing custom binding. It is much easier from the developer point of view, much harder from the user point of view.

My objection is for dumbed-down tools, not for the existence of the tools. I don't think that it is a good business decision to make use of those for anything but a demo, and I believe that I can, with the use of good framework and maintainable practices, get faster velocity than anyone using the wizards for most kinds of applications. This include the forms over data approach, by the way. <% EditForm(Table: Customers) %> is faster than doing dragging a table to the page.

A *large* number of applications have a clear set of requirements, and they won't be extended in the future.  You need to handle the requirements that the business users require right now.

If an application takes less than a man month to write, you are going to need to maintain it, simply because it is not sustainable to keep adding features to such an application without changing things. Doing it in a way that help maintenance is valuable, even if the application is not going to be significantly extended later on. Fixing bugs, working with the code, etc are all much easier when you write with maintainability in mind. And it is not as if maintainability is some painful tax that you have suddenly acquired, it is simply what happens when you write good code.

And it is *unarguable* that it is easier to use, say, the ObjectDataSource, to accomplish this than to do MVP/MPC.  There is *no* argument against this.  None. 

Ha? I would certainly argue that. Just try doing anything remotely interesting with the ODS and you will see my point. The ODS is just a way to call a method to get a data source, and it has such wonder methods that pass me IDictionary of parameters, and expect me to do something with it. That may be good for tabular data, but I don't have that.

It is unarguably easier to use a wizard or designer to design the vast majority of applications that are used by businesses around the world. 

Again, I would certainly argue that. Because you ignore the part that happens after you generated the grid or the form, where you now need to do all the tweaks that the client want (debt rows should be yellow, big debt rows should be red, late returns are marked with an icon, give me row level security and column level filtering, etc).

The code that is produced by using designers, wizards, etc. is more easily maintained by people who aren't alpha-geeks.

Here is something that I can't really understand. If alpha geeks can't maintain this code, why would others be able to do so? Unmaintainable is just it. And I have worked on creative solutions to a lot of technical problems that stemmed from the fact that I wanted to do it the RAD way, and have came to regret it.