Software Immitating Real Life Solutions: A Design Trap

On Monday, I wrote an extended post on calculators in which I mentioned a common software design pitfall. I wanted to talk about it in some more detail because it is a fairly interesting topic. Software calculators are excellent jumping off point for this discussion because they help to illustrate the issue quite clearly.

If you work as a software developer, there will be a lot of times when users will ask you to automate or digitize some existing process. There is something that they are doing on paper or with some cumbersome, electronic tools, and the want it to be done with computers. This is where you step in. You analyze the process, gather the requirements and design a solution. What the users need, is an improved, automated version of that process. But what they think they need, and what you end up building is usually a direct imitation of their process in software. Which is nowhere near as helpful as it could be.

Let’s use my calculator example. Lets say software calculators do not exist. A user brings you his desk calculator: a really cheap, simple, solar power thing, and asks you to make something like it in software. What you probably will end up doing is this:

Flawless Implementation... But stupid...

The standard windows calculator is pretty much exact replica of a real life calculator, along with all of its flaws and hardware limitations. The calculator on the left can only display a single result on it’s screen, because it is using a tiny low powered LCD and has a very limited on-board memory. The calculator on the right, has no such limitation. It could easily use a bigger output window to display a scrollable history of results but it does not? Why? Because the developer who made it was more concerned with imitating the real world object than with actual usability features. This might be an arguable point, but IMHO a historical display would be much more useful than strict adherence to an established calculator look and feel.

The problem is that the designer of the calculator application probably never even considered this feature, because it was not part of the requirements. The requirements were based on the real world calculator which used LCD for output. So the original requirements document probably specified that output is to be done in a text box that can only display a single number at a time. Why? Because that’s what the user requested. The user wanted a software calculator, and so this is what you are delivering.

As you can see this is a very complex issue. It is easy for me to sit here, and poke fun at a badly designed software calculator, but you can’t really take too much liberties with the user requests when gathering requirements. I might think that historical display would be useful, but frankly my customer may not care. So I might end up building and billing them for a feature they not only did not request, but also did not need or care for.

It all boils down to gathering requirements. In my opinion this is by far one of the most difficult, and most important parts of software design. If you don’t get this part right, then the entire project will be off kilter. And even if you get the all the requirements down, you may still end up building the windows calculator. An exact replica of a very, very limited tool.

The problem with this design stage is that most of the time users don’t know what they need. Firstly, they don’t know how to articulate their needs to you because they do not speak the same language. What you may call a radio button is a “thingie” to them, and your combo-box is a “whachumacallit”. Half the time talking to users is like playing Pictionary.

Secondly, what they think they need is not always what they really need. For example, a user may ask you to implement a desk calculator application simply because they have never used a graphing calculator. I’m still using calculators as a metaphor. Most kids in US get exposed to graphing calculators in high school or earlier. But I’m using this as an example where user wants you to implement something really simple and basic because they don’t know a bigger and better version of that thing exists. They don’t know that a calculator could actually solve symbolic equations for them, do unit conversions, trigonometry, calculus and etc… And sometimes there is just no way of convincing them that they could use these extra features. Sometimes the only way to do it, is to build the basic calculator but use a design that would be easily extended. This way if six months from now they realize they want all these extra features you can add them without re-designing the entire app.

Thirdly, it often does not occur to them what can be done with automation. It is very common for a user to request a calculator app, when what they really need is something entirely different. And you won’t realize that unless you ask them all kinds of silly questions. Like, why do they need the calculator. It’s a crazy thing to ask, right? But sometimes the answers may surprise you. For example, your user may tell you that they need it to crunch numbers for this lengthy report they need to submit every day. In fact, they do the same batch of calculations every time – all that changes is a few key values. So in effect, what they really need is an automated version of that report. You could easily build them a form that would allow them just to key in the few variables, and then print out the results. But it simply never occurred to them to ask for that. They figured a software calculator would be nice because they could copy and paste results instead of keying them in avoiding typos. But they did not make the next obvious mental leap of imagining their whole process being automated.

Believe it or not, this happens all the time. I have learned the hard way to ask silly, crazy sounding questions when gathering requirements, because half the time the next thing you hear them say is “Wait… You could do that?” Users very, very frequently underestimate what computers can do for them. They also overestimate, but that’s a topic for a whole other post.

Let’s talk about real life examples. Have you ever run into this issue? Are you guilty of building such an application? I know I did this a few times, though I don’t think I ever created anything that would be worthy of a The Daily WTF treatment.

One thing I remember making is a bunch of VBA macros that would import specific tables from excel into a word document, fix page breaks, change headers/footers, etc. Essentially what they wanted was a way to imitate what an actual employee would have to do to create a particular report. The problem was that the employees were all technology challenged and would constantly paste in tables as pictures, mess up the formatting, screw up page numbers and etc. So some reviewer would always get stuck with the task of fixing all that shit. Of course what this company really needed was to replace their mish-mash of word and excel documents with a full blown desktop application that would validate user inputs, crunch the numbers, do some post processing and then automatically generate the report document in a PDF format. But that idea was shot down every single time we brought it up. Instead we ended up with mountains of VBA code in both Word and Excel documents leading to lots of interesting version miss-match issues and annoyed users ending up copying and pasting data into blank worksheets to get around the validation scripts and restrictions we were trying to enforce.

But that’s kinda boring. So I have a funnier story. The Chinese food place near my work used to accept orders via fax. They had check-boxes on their menu, so you could simply check all the stuff you wanted, fill out a sheet with your address and then fax it to them. It was kinda silly, but it worked. Eventually though, they decided to catch up with the times, and finally implemented an online ordering system. Naturally, I decided to give it a whirl.

The website looked crappy, but I didn’t mind. It was pretty easy to navigate, and placing an order wasn’t a major headache so I did not hold the outdated look and feel against them. I was actually happy that they finally upgraded their technology.. Up until I submitted my order and saw a progress bar, accompanied by a stern blinking warning not to close the window until I get an order confirmation. The text underneath the progress bar was saying stuff like “Establishing connection…”, “Dialing..”, “Connection busy… Retrying…”. It went on like this for about 5 minutes before the order finally went through.

At that point it dawned on me: they did not upgrade shit. They were still taking orders by fax. Someone simply wrote them a front-end web application that took the order from a customer, and then launched some sort of a faxing application to the restaurant. I couldn’t believe it, so next time I was picking up my food there I asked them about it. The lady at the counter smiled at me, pointed at the dirty old machine in the corner and said “Yeah, you place an order online and it comes out right here. Pretty cool, huh?”. All I could really do was to nod in agreement. Though cool wouldn’t be the word I would use to describe it.

How about you. Do you have any examples like this? Let me know in the comments.