June7 and I think similarly in many ways but I differ with her on one point. The wizards are GREAT ways to quickly build a scaffold on which you can go back and customize things. Yes, they are as dumb as a box of rusty garden tools - but they are effective when building certain types of command buttons, combo boxes, list boxes, and special events.
One method I used to make things go faster was that in a particularly large app, I realized that I would have MANY forms that were going to have to do similar things. So I built a couple of "faceless" template forms that had a bunch of command buttons built in ahead of time.
For instance, my table maintenance forms all would have command buttons to SAVE (any edits), UNDO (any edits), CREATE (new records), DELETE (old records), CLOSE, and FILE TR (pop up a trouble-report form). They would all have the same logo in the upper left corner, they would all have titles in the top center area, and they would all show the user's login name and role (which I knew I would look up from a Users table). They would all have the same look-and-feel so they all had the same background and color scheme. There were other things behind the scenes, like BeforeUpdate events so that you could not accidentally update a record by navigating, you had to SAVE. They had audit logging built in to show what form, what record, and what user were involved in anything permanent like SAVE or DELETE. They had common error trapping support routines so when you trapped an error, you made one subroutine call to do the pop-up box (if you wanted it) and the error logging. When I was finished, perhaps 50% to 60% of what I was doing on that form behind the scenes was already handled even before I filled in any .Recordsource or controls. Then each time I needed to do that same sort of thing, I just copied the template and customized it for its final purpose. In my case, turned out I had at least two dozen of the maintenance forms for over two dozen tables.
The problem with code generators in general, and perhaps the reason that June7 is down on the wizards (which are, after all, code generators) is that "automatic systems" have no imagination, no guarantees of efficiency, and at best a highly limited style. It is why so many data-driven design systems are losing ground. The key to such systems is the code library from which they can draw, and I learned this rule a long time ago: 'One size fits all' rarely fits anyone.
I worked for a company (a long time ago now) that tried a system that automatically knew what to do with your data as soon as we designed the database. And it was right enough times that we were ahead of the power curve. But we ALWAYS had to customize. We were in the oil and gas industry and were doing leak detection as a feature on one of our pipeline control systems. We had a GREAT algorithm that complied with EPA standards and treatments. It understood viscosity, used virial equations to account for gas dynamics at high pressure, had lots of features. So we included it with our systems. Five years after we introduced it, we had 24 customers and 25 different leak-detection algorithms - ours and each of theirs.
Therefore, I understand why some folks are down on wizards. But when your goal is a RAPID (stress rapid) application development, the Access wizards can get you up and running fast. Then you refine the product by stepping in and tweaking or (as needed) replacing the code that was built for you.