php[architect] Home

Opinion: Why Software Fails

Posted by on October 10, 2011

What makes software fail? A lot of software projects are outright failures: botched feature specs, missed deadlines, poor functionality, security holes, and so on.

But there is a much subtler category of failure that is much harder to spot and address: the lack of usefulness.

Just last week, I took my car in for maintenance—nothing special, just an oil change and a tire rotation. Now, I’ve taken my cars to the same shop for at least ten years, and they’re usually quick and efficient, as they should, given that these are routine tasks that any mechanic should be able to handle—well, quickly and efficiently.

This time, however, things were distinctly different: the shop had switched from its old, terminal-based computer system to a new, “more modern” system based on a GUI operating system that shall remain unnamed.

What a disaster! The shop’s productivity had dropped dramatically as the techs struggled to figure out how each part of the new software worked and made mistake after mistake, resulting in frustration on both sides of the counter.

Clearly, that software is a working failure: it probably performs the tasks that it was designed to perform, but not in a way that actually helps its users do things more easily and more quickly.

This is a much more common problem than engineers and architects are willing to admit. Far too often I see someone in charge of writing a piece software worry about how a product works without paying so much as a passing thought to whether it actually works the way people expect it to.

The truth is that we are, by and large, stuck in a reality where software somehow equates with automation. We worry about speed, performance, and scalability, and see our job as that of simply providing a tool that makes a repetitive task easier.

This approach, however, betrays a dangerous underlying assumption: that the user already knows how to perform that task—which, unfortunately, is almost never the case.

Take, for example, time-management software. There must be thousands of to-do apps out there, written for just about any platform imaginable.

It’s easy to see why: on the surface, writing a to-do list application is a simple problem that pushes many of a programmer’s favorite hot buttons: data storage, synchronization across multiple devices, perhaps even a touch of user-interface design.

You’d think, with all these thousands of programs at our fingertips, that the whole of humanity—or at least that portion of it who has access to computers—would have, by now, become perfectly organized.

But they haven’t.

You see, the problem that people have is not one of automation: it takes all of a piece of paper and a pencil to handle a to-do list; in fact, I would argue that’s even more portable than just about any piece of software you can write.

The reason why people can’t get organized is much simpler: they don’t know how.

Now, obviously that’s a much harder nut to crack. How do you write software that teaches people how to become more organized? I suspect that even the experts wouldn’t know where to get started.

Yet, that’s exactly the kind of problem that to-do lists should solve, and they pretty much all fail miserably at the task, even though they are perfectly functional software programs.

And that, more often than not, is why software often fails while being perfectly successful: because it simply automates instead of encapsulating knowledge that goes beyond the user’s own.


About the author—Marco is the keeper of keys and Chief Garbage Collector at Blue Parabola. He can be found on Twitter as @mtabini.

 

Responses and Pingbacks

Another way to phrase it is too much of a change at one time. If the new gui looked the same as the old system everyone would already know how to use it. By making a better(more organized) system, users instantly lose any experience they had and they feel like the time they put into learning the old tool was wasted. This makes them dislike the new tool regardless of how good it is, and eliminates any loyalty they once had towards your product.

This is a bigger problem with out of the box software, which is why Microsoft is reluctant to make major changes all at once. MS Office looks and acts almost the same as it did 10 years ago (the ribbon being the only major design change). GUI changes should be small with easier to see benefits. New functionality should be integrated into the existing design whenever possible. Major overhauls to reorganize the gui should be staged to allow the users to follow and understand the reasons for the changes.

 

Great post Marco.
I was blogging about the value of software or better the lack of it just yesterday (if anybody cares go to http://softwaredev2k.com/2011/10/understanding-the-value-of-software/).

I also tend to believe that some software is developed disconnected from the end users. Eventually developers produce useless software because they do not listen/communicate with their end users or in the worst cases do not even know the end users exist. I happen to work in an environment where the developers’ main concern is how to create the code rather than who they create it for and for what purpose. If someone wishes to read more on this, detailed thoughts (or rants depending on how you look at it) can be found on http://softwaredev2k.com/2011/10/communication-between-developers-and-end-users/

 

when comes to efficiency, the weirdest user interface wins: try to get a look at the screen when you use manual check-in for your next flight. when there’s something to query with your data, the lady types cryptic 3 letter codes and gets the response in cryptic 4 letter codes… there will be no gui, touchscreen, voice or whatever in the next 25 years…

 

Leave a comment

Use the form below to leave a comment: