Many years ago when I was working on my first FoxPro book, FoxPro 2 Programming Guide, and I wanted to include several chapters on how to use the wizards provided by FoxPro to create forms and reports to even menus. However, my editor Lance Leventhal insisted that real programmers DO NOT use wizards and that he would not allow me to include those chapters in the book. I continued to argue for the inclusion of these chapters and eventually won but I think he was disappointed to have to include them.
Lance’s background came from assembly language programming and he wrote quite a few books on assembly language programming for many of the early microcomputer processors. His experience as a writer was much greater than mine since I had only written one previous book at the time on the Apple II. However, I did learn a lot about how to write technical books from Lance and will always be grateful for his mentoring.
In fairness though to his opinion on wizards, I suppose the use of wizards was not a big thing in his programming world, at least not as big as it was in FoxPro. However I totally bought into the concept of using the FoxPro wizards to help build my applications.
So now why do my co-workers hear me complain about the use of wizards? Well it is not so much their use, but their overuse that concerns me. A few years ago we brought in a consultant to help with some programming projects because our regular team was fully engaged in the planning and roll-out of our public facing school SharePoint-based web sites.
While we were busy with our project, the consultant, decided rather than to just write the application that was needed, to write a wizard that would write the application. Basically every form and every report was created through his wizard interface. Any changes to a form or report was accomplished by first changing the wizard and then regenerating the application. That might sound great at first, but there were several problems which surfaced only after the consultant moved on and we were left supporting application on our own.
The first problem was that the team member assigned to take over the application not only had to learn the processes needed by the application that were very complex and deserving of another story, but he also needed to learn how to work either within the wizard or around the wizard to make changes to the code. If he tried to work around the wizard, the next time the wizard was used to regenerate the forms or reports, all of the custom changes were lost. On the other hand, the wizard generated such complex code that it was hard to make changes manually in the first place. Therefore, either method of changing the code took more time than I felt it should take for what in many cases should have been a simple program update.
Of course most programmers don’t think about time, they think about the challenge of the task. But because this application was in a constant state of flux, the changes quickly overwhelmed the programming. We finally reached a point where we no longer believed the current application could be effectively maintained and needed a major overhaul. This would result in a decision to either rewrite the entire application from scratch or look for a third party application that would do most if not all of the functions needed. In the end, management decided to look for a third party application.
The moral of this story is that this failed project attempted to make wizards do too much. It tried to make the wizard the application itself rather than use the wizard to save some initial design time. Wizards can be great to get as much as 80 percent of the work done quickly, but then the programmer must take over for the 20 percent balance to customize the code to meet the specific application needs.
Quite honestly though, the wizards in Visual Studio and SQL Server Reporting Services already meet this need most of the time. Most programmers don’t realize this but much of the programming needed to build a window, a dialog, or even a report is now done for you as you visually design the user interface. After the basic visual design is complete, the programmer can open individual controls and add code to events to make the program actually do what they want it to do. Writing another wizard to perform these same tasks is redundant. Writing a wizard to help write the code for the control events seems to me to be trying to automate too much effort for too little return. If a programmer can write the code for a wizard that writes the code for control events, why not just write the control event code first and save yourself a lot of time?
The bottom line is that I’m all for using wizards, but only up to a certain point. Wizards can help build code for easily repeatable activities such as building the basic form or report infrastructure. These are activities that every application needs and can easily be generalized. Custom programming activities should remain custom programming activities. Don’t try to create tools to create custom code because all you have done is add another layer of complexity that can break or need to be maintained.
I’m sure that over time, wizards will continue to take over more of the programming activities that must or should be done manually today. Does that mean that the need for programmers will disappear. I doubt it. For every advance in interface design I’ve seen over the years beginning with dBase II’s tiny dot prompt to today’s very rich user interfaces, the need for programmers to customize the code generated by wizards has if anything grown.
With that said, I’m about to launch a series of Saturday blog posts on using macros in Excel. Macros are wizards. You can have Excel record a series of keystrokes and automatically generate the corresponding code to perform those actions. (That’s the wizard part.) However, sometimes you cannot do everything you want by just recording your keystrokes. You need to get into the generated code and tweak it just a bit to suit your needs. This series of articles will cover this distinction using the built-in Excel wizard to build much of the code as possible, but then allowing us to go into the resulting code to make adjustments rather than attempt to modify the wizard to do everything we need