Wizards in software are mostly uninspiring solutions to bad design

Here’s a thought maybe even a provoking one, as everyone seems to have reached at the conclusion that wizards in software are good. The general and agreed upon argument goes; that a wizard shields the underlying complexity of the software. That’s fine. However, the question quickly becomes for whom or why do you need to shield this complexity. For the user, mostly the casual user, as the assumption in software design for business applications seems to be that the non-casual user knows how to operate complex screens or at least have read the manual.

But why would a casual user need to use the same software as a power user? Or at least why and where do a power and casual user share the same area and functionality of a certain application? Wouldn’t it make more sense to build different screens targeting the primary user – being either casual or power user? Rather than trying to cram everything into one screen? And then after cramming everything into one screen for the power user, develop wizards to help the casual user?

I can think of one specific area where wizards do make sense mostly concerning installation, configuration and setup of applications. But that’s not really shielding functionality, that’s more semi-intelligent template generation.

It should trigger a warning if you’ve either designing an application and you’re thinking: “maybe we should implement a wizard to make it easier”. Warning, you’re heading down the path of providing an uninspiring solution to a bad design. Don’t go there. Stop and rethink your design and redesign so the application targets the primary audience and provide the level of functionality needed for that audience. Strip away unnecessary functionality, and stuff it somewhere else, and let the power user go seek it out if needed.

#programming #wizards

Methodologies, Better Software and Requirements


Methodologies are like patterns, best practices, recipes or how-to’s. They describe how to get from A to B. But none of them claims that it’ll lead to better software, whatever better software means. Actually, that’s not totally true – some of the newer methodologies got some interesting claims on the subject of providing quality wise better software.

When discussing better software most people thinks about the quality of the software, seldom does people consider whether or not the software does what it’s supposed to do. Probably more correct to say, that people don’t factor the functionality in as part of quality. Can be observed when discussing functionality and/or quality with users, they don’t qualify a missing feature as a quality issue, but as an enhancement – and so do we as software engineers.

Okay, so 2 different objectives when developing software: 1) develop the right product and 2) in the right quality. Right product means that the product does what the user expects it to do, contains the right features. Right quality means that it does the former, without trying to ruin your life in the process – by – say – continuously crashing, or by any other means makes it unnecessary complicated to get your task done – hit the [ANY KEY] (some users actually got confused and tried to locate this key – no kidding!)

Question becomes, can a methodology help you to build the right product in the right quality? Personally, I don’t think so. However, a methodology – actually any methodology – can be a good starting point for building appropriate structure into a new project. Existing methodologies can be a source of inspiration on how you could do it. It’s much like a food recipe, if you follow it 100 %, you get something that’s not quite like on the picture and it doesn’t really taste as good as it looks (on the picture in the cook book that is).

That’s all good, but how do we then built the right product, in the right quality and at the right time? The answer to this perpetual question, and it is really perpetual as it’s been tried answered in tons of articles over the last 30+ years, isn’t 42. Probably more like 42+ something.

The Requirements

This may seem bleeding obvious, and it really is bleeding obvious – but apparently it’s very hard to get right, otherwise, we wouldn’t have late projects, wrong applications or defunct products. The key to the 3 R’s is the 4th R, being the Requirements. Having the requirements sorted out allow you to built what’s expected, to provide more accurate estimates (not just guestimates, or wise ass guesses) and also allows you to construct the test cases needed to validate the software against the requirements. Pretty obvious – huh? Well, apparently not!


If requirements are so important, why not gather them all up front before even starting to code? Not a bad idea! And in essence that’s what the Waterfall methodology is all about. Phased development plan, with well defined processes and stages for moving from one phase to another. Widely adopted and used methodology until the late eighties. For the waterfall methodology to be successful you need to be dead sure you got all your requirements right in the initial phase of the project, if not – there’s a high probability you’ll be hosed when delivering, and users will go: “Dude, I still can’t find the <ANY KEY>” or worse (maybe) “Dude! This is what I asked for, but didn’t expect” (more on this particularly scenario later).

Lots of empirical research indicated that waterfall works fine for projects that’s either extremely expensive or, if done wrong, kills the end user. Either way, if you don’t get the stuff right you’ll either be prosecuted and go to jail or lose your business. Huge motivator for getting it right – right?

Lots of other empirical research showed that for software projects, the whole idea of understanding the problem domain upfront seemed impossible. Mostly due to the shorter life cycle of software products compared with their more expensive hardware ones. Also, the investment model is different for software products, as the majority of the costs are salary. For e.g. chip manufacturing there’s a huge initial investment prior to producing, which is building the manufacturing plant.

Post Waterfall

Gathering requirements is an extremely difficult task, mostly because most users when asked what they want go: “Dude, show me what you can do….” or “something like who knows, that can – you know – when you hit the – whatever key…” Sigh! Very hard.

It turns out that users really can’t relate to the majority of the means used to communicate the end result. However, what users can relate to is the end result – the product, but problem being that it’s hard to change the final result. Somebody then came up with the idea of iterative processes, which essentially breaks down the development cycle into mini cycles, that each have all the phases known from the waterfall methodology: requirement gathering, analyses, design, implementation and testing. But added an evaluation phase, where the users evaluate the newly developed functionality.

Over time more and more iterative methodologies have emerged, but they all originate from the idea of splitting the phases into smaller cycles and including the users to evaluate the result on an ongoing basis, until the product is ready.

Better Software

If better software is defined as the sum of RP + RT + RQ where RS is right product, RT is right time and RQ is right quality. And we agree that the requirements actually are a key driver for obtaining RP + RT + RQ, then I believe that newer methodologies (or at least all methodologies deriving from iterative ones) will provide better software.

This being said, then personally, I believe there’s a small issue with not knowing the requirements initially as it’ll be very hard to get an initial estimate to cover RT. There simply need to be an initial phase prior the iterative process called high-level requirement gathering. The product of this phase is essentially a rough blueprint/proposal that top level explains the purpose of the system.

This leads to: for RP + RT + RQ = True, requires R. Meaning that to deliver right product, at the right time in the right quality you need to understand the Requirements.
#requirements #programming #software #engineering