+972 52-548-6969
Are Designers, Wizards, etc. inherently Bad?
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.
Comments
The problem, you see, Oren, is that you are a heretic.
Keep it up.
It is as you say, the designer only give you 50%, then when you need to add the specific requirements you end up having to rewrite the code the designer generated because it could not support it or if it could the code would just be a mess.
Well, i´m moving from Delphi way to an OO way using c#. As i´m experienced using RAD, i can say one thing: They are bad and good at same time. RAD doesnt take the beginner to understand concepts, it make beginners only understand the "HOW", and not the "WHY". Thats why a lot of Delphi programmers, here in Brazil, have difficulty to understand a good design, a good OO approach. They are used to just "drap and drop", "follow Wizards up", etc. And when you show them a sample implementation of an ADO pattern or MVP pattern, they say "ah thats so hard.... why do that ?"
I dont know i´m being clear, what i mean is that Designers can be good, since you understand when you should use them or not.
Tools are fine to have. However, I strongly believe that one should understand and be aware of what the tool is doing.
Preferrably you use a tool to take care of things you do over and over again.
ie. I used a tool initially to generate my NHibernate mappings files. Then I found out I didn't really know how the mappings worked.
I went and did them by hand. I have a much better understanding of how they work now.
At this point, I could return back to the tool, and with the ability to verify the tool is doing what I want.
The tool itself isn't a bad thing at all, it's up to the developer to educate on what the tool is doing - not all tools do what you expect them to!
I use a WYSIWYG editor, but I often have to go and validate/modify the html. Simply because I want the editor to do some RAD for me. But I certainly know html and I often validate it is doing what I want.
Tools can be useful and can get the job done fast. But the highest cost in development in maintainance. If there is anything that needs to be changed, you are screwed. Take ActiveWriter for example that generates AR classes for you and also adds the attribute. I doesn't support Increment Generator type, plus it dumps all the classes in one file. I don't want all of my entities in one file. If you manually change anything and regenerate the mapping, boom everything you did is gone. Eventually you findout that these tools take more time to work with than saving your time and not to mension that you are bound to functionality it produces. To me it seems like that the code generators are not that much of good tools. Plus if you do by hand, you know what you are doing as Steve said. Also Jean Paul (JP) believes in coding than using code generator because he always writes the test code that defines the behaviour and then write the code to pass it. I am following the same coding style and loving it. MVP rocks as it helps me write test cases very easily and makes it very easy to maintain code.
I think the underlying point in both posts here is "designers and wizards are good, unless they spit out code that forces me to do more work than I would have had I written the code by hand in the first place". I can agree with that point.
Do I want to go back to a time when you and to hand-draw your windows and place the pixels precisely using code? Not really. Some designers just focus on the layout and allow you to hook events and references up to your code. Apple's Interface Builder is great at this and it appears the Blend tool will be too, Others, like the Visual Studio designer, try to guess your intentions. Meaning that you have to jump into the code and tweak things.
The query builder in SQL Enterprise Manager is great at getting me 80% of the way. I use it whenever I have complex joins to get started. Then the other 20% is all hand coded. But, in that instance, the designer/tool doesn't get in the way. If I change the SQL, it doesn't re-write it for me later.
And yes, there are a LOT of developers that need to get over themselves. Always has been, always will be.
"If alpha geeks can't maintain this code, why would others be able to do so?"
Because often with wizard generated code, you have to give yourself over to the wizard and let it handle the code. Alpha geeks won't let that happen. They have to dig in and look at the code, then change it, then wonder why the wizard overwrote their changes, then re-change, then curse the wizard.
I don't agree. The point is that it is very easy to get to the limit of the wizard very quickly. And then you are in a world of hurt if the wizard is not producing good code and is round trippable.
That is not a flattering image. Don't know many that would fall to that twice, frankly.
I started to respond but I think I exceeded the comment length limit or something so my response is here......
http://www.blogcoward.com/archive/2007/06/14/29.aspx
As Oren mentions, the main problem with wizards is that they produce 80% of the code quickly, but put you in such a straightjacket that the remaining 20% is more difficult than it would be if you just implemented the whole thing from scratch. So I too have become disillusioned with wizards. What I don't understand is the conceptual leap from visual designers are good for laying out UI (I agree!) to visual designers are good for coding everything (I disagree wholeheartedly). Ever try to understand a complex BizTalk orchestration. Even on large monitors, you can't see the whole orchestration. The same logic in C# (or a custom DSL) wouldn't even be half a page of code. Where is the logic in this?
But as a more general comment (and significantly shorter to boot), I agree with Scott and Steve.
If you use wizards, it is good to know (at least some times) what they are doing behind the scenes (this is why I have a highly favorable view of code generation, because I know what each line of the CodeSmith templates are doing). And with partial classes, you can in many situations override what the wizards produce.
But it isn't always necessary. I've built an app that uses typed datasets and table adapters and it works just fine (though I would normally never use typed datasets). When requirements changed so that the underlying SQL changes, re-run the wizard, maybe minor changes in a partial class, and you are done. Meets the business requirements, easy to maintain.
And I don't feel at all bad that I haven't spent much if any time at all looking at the generated code because it isn't necessary.
To what extent is this a debate over how much can be done declaratively vs. imperatively/functionally/etc.? WPF and its XAML spring to mind. I do have some issues with it, especially with the magic strings employed that don't necessarily cause compile-time errors, but I did find the declarative nature though-provoking. Perhaps this is a better way to frame the discussion? I'm under the impression that wizards and whatnot do better with declarative code than anything else.
Ayende, do you have issues with the code generated by the WinForms designer, assuming one doesn't do anything really fancy and populate a tree with the IDE GUI? Almost all of my InitializeComponent methods contain code that is essentially imperative; the biggest improvement I can think of would be to have nested controls be nested in declarations, something that could be done quite well with an object literal syntax IMHO.
Ayende, I think it would be good to come up with a more comprehensive, normalized list of where MS designers break down, where it becomes more effort than it's worth to use the wizard. I like to think of this as discovering boundary conditions, which can be incredibly useful for understanding software and frameworks and whatnot.
Luke,
I like the idea of XAML as a way to define the UI. I think that it is a good use of XML and that in that it is both readable by humans and tools. That is much better than the WinForms' initialize method.
Issues with the WinForms designer? Whenever I need to look it, yes :-) That doesn't happen often, I am not doing enough WinForms stuff to get to the pain points. Getting the nesting in a way that I can see is great.
Any time that I want to add custom behavior to the equation, the wizards breaks down. Comprehensive it is not, I agree. I will give it some thought.
Comment preview