Why Software Sucks, And Can Something Be Done About It?

CPNABEND tipped us to a story carried on the Fox News site, pointing out that a lot of programmers don't understand their users. David Platt, author of the new book 'Why Software Sucks ... And What You Can Do About It', looks at the end user experience with end user eyes. While technically inclined individuals tend to want control, Platt argues, most people just want something that works. On the other hand, the article also cites David Thomas, executive director of the Software & Information Industry Association. His opinion: Users don't know what they want. From the article: "'You don't want your customers to design your product,' he said. 'They're really bad at it.' As more and more software becomes Internet-based, he said, companies can more easily monitor their users' experiences and improve their programs with frequent updates. They have a financial incentive to do so, since more consumer traffic results in higher subscription or advertising revenues." Where does your opinion lay? Should software 'just work', or are users too lazy?

one example of too many

One example I encounter almost every day is the notion of a computer's "state". People just want to turn something off and on, not easily abstracted for computers.

So, there is this myriad combination of "states", not too complex for slashdotters to understand but off the scale for lay users. It doesn't help we use "our" terminology. I've stopped trying to explain and describe the difference between "hibernate" and "standby".

Files, directories, logical drives..., all foreign and abstract curiosities to computer users -- most are technical artifacts from early on abstractions. It's not a wonder these lexicons ripple out the the general population, unfortunately it's of no use to the general users and mostly to their detriment.

I don't know how to get there, but users/people want computers to behave like toasters. They want very simple, limited-option and intuitive behaviors. Not all software lends itself to those but I think there is a much happier in between, and the group that can move is the programming group. I don't think the general population will ever educate itself about the differences between relational/hierarchical databases, the differences between NTFS and VFAT file systems, nor do I think they should be asked to know.

The closest I've seen to getting "there" in computers is probably Apple... I've seen novices sit in front of Apples and almost immediately be able to be productive.

The second closed I've seen is Unix/Linux, etc... not so much because of it's ease-of-use, but because it's one of the most consistent "flavors" of computing I've experienced (NOTE: I'm not discounting the complexity of Unix, it's certainly not for novices, but at least it's consistent).

One of the most popular applications I've written was one where the interaction with the user was basically a singly input field, a la Google. Users would instinctively type anything in the input field, and the application would do a pretty decent job of offering meaningful results. Analysis of logs showed users typically received meaningful results from their "input" 80 - 90% of the time. Granted it was a narrowly defined application, but I've seen indecipherable interfaces on top of narrowly defined applications.

The best general computing out there is something I'd predicted long ago, devices that are for narrowly defined and specific use with high powered computers underlying the gadgetry transparently (think TomTom (gps), ipod (no, I'm not a fanboy), etc.)

Ironically, or perhaps paradoxically, the most dominant technology available is the least intuitive to just sit down in front of and use. Of course, there is a latest and greatest new version out this year that should fix all of that. .

Bottom line, my opinion, users are not lazy, they just want to get some work done without needing the equivalent of a Bachelor's in Computer Science to get that work done.

Re:Fine, not lazy

But taxis and buses don't damage the roadways and the other vehicles on it during ordinary use.

Au contraire! A bus does more damage when it runs across a roadway than would a line of cars with the same seating capacity because a larger amount of weight is put on the four (or perhaps six wheels - either double-axle or dual-wheel in the rear) wheels than from any car.

This is the reason why we have laws that say that vehicles over certain weights may not travel through certain neighborhoods except to make a delivery, and why you are supposed to need a commercial license to drive a vehicle over a certain weight. Of course, we don't actually enforce these laws because it means some rich people in LA and SF wouldn't be able to drive their Hummer home...

Re:Fine, not lazy

But learning to drive is not the same as learning to fix and maintain a car. To drive you only need to operate the car, and to own it you only need to remember to take it into the shop occasionally to get looked at.

Computers, right now, require you to be mechanics to drive the car, and users don't want to be mechanics. They want to get their work done. Part of this is changing user expectation (so that they know to get routine maintaince from someone trustworthy), but part of it is building the systems so they can survive routine wear and tear for an extended length of time, without the intervention of computer 'mechanics'.

Wanting less work != lazy

Computers have exactly four purposes:

1: Pr0n
2: Games/entertainment
3: Communication
4: Doing our work for us.

Building machines to do your work for you does not make you lazy. Using the machine that someone else built also does not make you lazy. In both cases, the machine is freeing you from a mundane burden so you can do something else more useful with your time. Making efficient use of the tools available to you is not laziness.

Laziness is when you push your own responsibilities off on to other people, without paying them for it (like, you know, leaving your dirty dishes in the office sink so your coworkers can wash them for you). Yes, payment absolves you of laziness since it is ultimately an economically productive action in and of itself.

Paying a developer for a program that "just works" isn't lazy, it is efficient.

End users don't like a complicated interface. Why should they? The less complexity they have to deal with, the more time they have to do something else that is useful.

Yes, some amount of complexity is going to be unavoidable. That's a fact of life. Users will naturally resist it as much as they can, but ultimately accept what amount of it they cannot escape. This is not a vice on their part, it is just a path of least resistance.

If you can design an optimized balance between complexity, intuitiveness, and productive outcomes in your user interface, your product will do well.

It is that simple.

Re:Wanting less work != lazy

Computers have exactly four purposes:

1: Pr0n
2: Games/entertainment
3: Communication
4: Doing our work for us.

Well, yeah, but the same could be said for paper products. :-)

I think that there are either;
-many other categories, such as art, research, etc,
-or only one category, which I would call "Stuff".

Re:one example of too many

Well said, yagu. For a good illustration of the truth of what you've written, try teaching a Computer Literacy class for adults who have never used a computer before. I got questions like "what's a mode?" and "why are these little arrow keys for?". If normal humans -- the kind who don't read Slashdot -- have trouble with concepts like modes and arrow keys, you can imagine how difficult it was for them to understand that, when their Word document disappeared from the screen when they minimized the window, it did not also disappear from "the computer", but was sitting somewhere invisible to them.

I think it would serve every programmer well to spend some time teaching novices how to use something the programmer finds simple, such as the Windows calculator, Notepad, etc., to see how "normal" users think and react.

Re:one example of too many

I don't agree that novices can be considered "normal." The computer illiterate are quickly becoming an oddity, a special niche in usability design. There's really no need to consider them anymore unless you have a special reason to.

The real question is how much sophistication can be reasonably expected from lifelong computer users. The file concept and needing to save one's work is an example of something that we've accepted that everyone can and should learn, in spite of the dire predictions of UI experts. The idea that people would be better off sheltered from the file concept is, in retrospect, pretty silly -- as silly as the idea of equipping an automobiles with reins and a whip so it would feel like a horse-drawn carriage.

I think we should stop projecting limitations onto humanity and see what happens. The typical "poor ignorant user" of 2030 is going to be at least as savvy as today's typical middle-class college student, and maybe more savvy in ways that surprise us.

Even Google can't do it...

Bottom line, my opinion, users are not lazy, they just want to get some work done without needing the equivalent of a Bachelor's in Computer Science to get that work done.

But what if its simply not possible to make things so simple that average Joe can "just do it"?

Everyone uses Google's search box as an example, but the fact is that that box is the front end of a task that is very easy to describe - "show me a list of documents that more or less relate to these words".

As soon as you stray from there into some of Google's other functionality you are into some far more complex screens that I personally have heard people confused by. Well-designed though they are, it sometimes just takes a fiew fields, links and words to make the interface powerful enough to be useful for the task at hand. This is even more so when there are financial ramifications to the task at hand, immediately requiring history, confirm dialogs, balances, tec etc.

As computer gurus our very DNA is infused with the belief that we can build it, and make it so simple anyone can use it.

Personally, I find that this feeling diminishes as the project progresses. Sometimes because we don't have access to Googe's level of funding for UI design, usability testing, etc. But often, in my opinion, because some tasks simply can't be made simple.

Re:one example of too many

I don't know how to get there, but users/people want computers to behave like toasters. They want very simple, limited-option and intuitive behaviors. Not all software lends itself to those but I think there is a much happier in between, and the group that can move is the programming group. I don't think the general population will ever educate itself about the differences between relational/hierarchical databases, the differences between NTFS and VFAT file systems, nor do I think they should be asked to know.

That's all good and fine, but there are cases, many, many cases, where users aren't able to use even the simplest interfaces. This can be expected of them, as the people unable to use these interfaces tend to be old people, while younger people immediately know how to use them regardless of previous training because they are at least used to the idea of an interface.

I used to work at wawa, and I can't even tell you how many people used to complain about how the touch screen ordering system was oh so complicated. The entire thing was self-explanatory. You touch what type of food you want, then touch the ingredients then hit complete. Not exactly rocket science. For these people even using a touch screen to manipulate words is something they are uncomfortable with. We cannot stoop to this type of illiterate and design software to accommodate them. They simply cannot be accommodated. People need to learn to read and interact with a basic interface, if they can't, then they will get left in the dust, same as other dinosaurs.

Re:one example of too many

I used to work at wawa, and I can't even tell you how many people used to complain about how the touch screen ordering system was oh so complicated. The entire thing was self-explanatory.

If it was really self-explanatory, then they wouldn't have a problem with it, now would they? Unfortunately, what might seem self-explanatory in hindsight to the developer, or to someone like yourself that's around it 8 hours a day, can be completely baffling to someone that's never seen it before. Take, for example, all those web sites with Flash navigation that force you to poke around with your mouse, trying to guess where where the menu is. The developers that created those atrocities thought they were 'self-explanatory' too ; the rest of us want to beat the developers with a stick.

Re:one example of too many

So, there is this myriad combination of "states", not too complex for slashdotters to understand but off the scale for lay users. It doesn't help we use "our" terminology. I've stopped trying to explain and describe the difference between "hibernate" and "standby".

You know, I think this captures the fundamental problem here.

From a technology standpoint we programmers think in terms of how the underlying stuff works. To us, it's clear what hibernate and standby are doing, why they're different and what the relative advantages and disadvantages of each technology are. However, in being so focused on the underlying technology and how it works, we start overlooking the problem that both technologies are trying to solve, which is this: how to extend the life of a computer (computer's battery, in the case of a laptop) when a computer is left on but is not in use--and do it in such a way that the computer can come back on relatively quickly when the user comes back.

Users want us to solve problems, we want to provide technology.

And so when the user wants to solve the problem "I walked away from my laptop for an hour; please make it so the battery doesn't drain dry when it is idle", we come back with "well, we have sleep and standby and hibernate; hibernate is really cool because the computer is almost completely powered off but standby allows the computer to come back a lot faster"--of course we're going to get a glazed look on the poor user's eyes. All he wants is to come back, jiggle something, and have the computer come back to life.

Unfortunately because we talk about providing technology and the user wants to solve problems, we then wander off grumbling "stupid lusers; they're not willing to learn how to use their computer." And the poor users stumble off grumbling "why do they make these damned thing so hard to use? I don't care about bits and bytes; just tell me what I need to do so I can get my important work done."

The really ironic part is that users are not stupid--contrary to about 90% (caution: made up statistic) of technologists complaints. They just happen to have a different job than us. I mean it's easy for us to look at some poor overworked doctor (for example) and claim he's a moron because he doesn't know the difference between suspend and hybernate--but then, the reason why he doesn't know the difference is because he's more worried about knowing the difference between opioids and non-opioid drugs and knowing which class of drugs will better relieve his poor cancer victim's pain.

Re:one example of too many

I agree with you about Macintosh, but Linux more consistent than Windows? Give me a break. Let's get past the /. mind-numbed-robot FOSS advocacy and anything-but-Micro$oft FUD for a second.

If there is one thing that Windows does well, it's consistency. Cut, copy and paste work the same in 99% of Windows programs. They do NOT work consistently across Linux programs that often use different underlying graphics toolkits, etc., and different shells, etc. Also every single one of the command-line utils in any flavor of *nix has a unique syntax. That's not consistency.

I'm not trashing Linux or glorifying Windows, but let's give credit where it's due. Windows is remarkably consistent and that is probably one of the main reasons for its commercial success.

the ninety ten rule

Ninety percent of your users will not have an opinion about your software.
Ninety percent of the users who have an opinion, will have a misconception about what the software is supposed to do.
Ninety percent of the users who understand what the software was supposed to do, will have a preconceived idea on how it should work based on their experiences with your competitors.
The final 10% of the people who have an opinion, have no misconceptions about the software, and have no preconceived idea, will have useful input.

Unfortunately 90% of those people are idiots.

Let's draw back...

...a few thousand miles.

If people are bad at figuring out what they want from a computer, and terrible at designing (which, yes, they are) then maybe the problem is that the computer sucks. General-purpose computing is best left in the hands of experts. That model worked for 20-mumble years, and it was a good one. It still is, if you need to get industrial-grade stuff done.

But "personal computers," to be distinguished from "desktop computers," are a bust. Ordinary people can't deal with the complexity, and attempts to make computers act like a friendly thingy with stuff on it all fail because the computer isn't a friendly thingy with stuff on it. It's a computer.

People need, say, the Pure-Digital video camera that lets you take digital video with one button, has no memory cards, and runs on aa batteries. They need the microwave oven with the popcorn button. They need the car with a computer in it so they don't have to know when to use the choke. Special, optimized uses of computers work great for ordinary people.

People aren't stupid, they just don't act like a computer. Maybe there's a lesson there.

Re:Let's draw back...

Reminds me of that Bible story where Moses was taking some escaped slaves for a walk in a desert that lasted some 40 years.
When asked why it took him so long to get to a free land, he replied that they had to wait for all the former slaves to die off, since only their kids could be trully free.

My point here is that most kids (9+ years) these days have no problem getting their family computer to do just about anything they need, so in 20+some years when their parents will pass away, all the 'luser' issues will go away.

Apple gets it right.

I totally agree that most software sucks. I'll even admit that some apple software sucks, but since switching (almost 2 years back now,) my world has completely changed. I'm no longer frustrated most of the time when working with my computers.

I've been a software developer for near a decade. There's two extremes to this, ignoring your customer, and letting them run the development, both are bad. The best path is to have some intelligent people in your company that sit in between customers and clients and act as a translation layer. Throw out the ideas you can't implement, give them the good ones. These people have to be at least partially developers themselves, they serve as architects as well as PR.

Customer Ideas -> Architects -> Code Monkeys

Of course it should just work.

On a completely different note, I just bought a guitar, but I'm going to return it because I think it should just produce the music I want to hear when I hammer at it like a retarded orangutang. Someone told me that I'd have to take the time to learn stuff like "notes" and "rhythm" and who-knows-what. That person obviously just doesn't know how to make a guitar. [/sarcasm]

Better analogy

It's more like buying a new "upgraded" guitar, and in order to hit any flats or sharps, you have to open a small panel on the back and hold down a button. Oh, and replacing a broken string may lead to complete inoperability.

Re:Of course it should just work.

Okay, so you're being sarcastic, but you're also missing the point. A better analogy would be somebody who wants to listen to music and is given a guitar rather than a radio. Sure, if they put in the time and effort, they could eventually learn to play the guitar and possibly even make better music than what they could find on the radio but it's not really a reasonable answer to the person's need.

Users don't make buying decisions

It's true that developers don't think like users, but that's not the only reason software is hard to use.

In most cases in business, users aren't the ones making software buying decisions. The organization makes choices for them based on a number of factors. There's no conspiracy against usability, it just has to compete with cost, features, regulatory compliance, and other considerations. Software developers naturally target the criteria that drive purchase decisions, even if the result is a compromised user experience.

This is just a little bit crazy.

I'm reading TFA, and some of this stuff is just silly.

For instance, the "Save" button. He argues that a statement that says "Do you want to save your changes before you exit" is a hard sentence, and that "Do you want to throw away everything you just did" is a clearer sentence.

The word "save" isn't that hard of a word to grasp. People save money. People save possessions. Saving documents is no different. Grade schoolers understand it.

What really cracks me up, though, is that he argues that when deleting documents, there should be *no* confirm. I've had a few times when that windfall was really helpful, when I've accidentally hit the delete button or selected delete, and then said "No, I don't really want to delete this file." He compares it to starting a car, where the car doesn't ask you if you want to start the car or not. This is a horrible analogy: the last time I checked, turning a key didn't do something as devestating as, say, deleting your car.

I deal with end users every day, and I've had many of them admit that they don't read error messages or confirm dialogues. If they don't read it, what difference does it make what's included in the dialogue? I've made messages that were very easy, simple to read and understand, only to have them overlooked.

Next, the author mentions that error messages need to state *why* something failed. Wait a second... I thought he was just arguing for simpler error messages, but now he wants to know specifically what happened? That's not exactly simplifying things for the end user.

Now, I'm not saying that it's all the fault of the end users. There are some rather atrocious error messages out there, but it'd be safe to say that there are more end users out there that don't read things carefully. Computers are a tool, not a replacement for thinking, and users need to know that in order to get the maximum use out of technology.

Re:This is just a little bit crazy.

This is a horrible analogy: the last time I checked, turning a key didn't do something as devestating as, say, deleting your car.

Well, outside of organized crime, anyway.

Tends to delete the user as well.

Re:This is just a little bit crazy.

The word "save" isn't that hard of a word to grasp. People save money. People save possessions. Saving documents is no different. Grade schoolers understand it.

Part of the problem is that computers intimidate users. They never know if it is going to break when they do something. "Save" is a term that is strongly associated with computers these days. Saving a file and saving changes aren't so much "saving" as they are writing something to a semi-permanent record. They don't fit well with the document/folder metaphor because on paper people save a file or they toss it, they don't save part of a file or undo all the writing they have done in the last hour but keep the file itself and the old work. On the back end saving changes or saving a new file is pretty much the same thing. You write to disk. It is not so in the minds of many users.

What really cracks me up, though, is that he argues that when deleting documents, there should be *no* confirm.

It is hard to see what the author is arguing from this brief bit, but he's right that their should not be a dialogue confirmation. Users already have a trash can they can look through and it properly asks for confirmation. When you delete a file, it goes to the trash and you can always take it back out. The huge number of dialogue boxes, particularly on Windows are a classic design flaw.

If they don't read it, what difference does it make what's included in the dialogue? I've made messages that were very easy, simple to read and understand, only to have them overlooked.

Many dialogue boxes don't even give the user a choice and most users simply click "OK' over and over again until it is a conditioned response. Worse than the number of dialogues is Window's penchant for keeping the buttons the same, which facilitates this behavior. Is it so hard to have it say, "Do you really want to throw this file away, (Throw it away)(Don't throw it away)." With such a message the user must read at least the button, at which point they know what action is being taken because the button is itself an action, not "OK."

Next, the author mentions that error messages need to state *why* something failed. Wait a second... I thought he was just arguing for simpler error messages, but now he wants to know specifically what happened?

Messages need to be fewer and clearer, not necessarily simpler. Adding more information in a dialogue is just fine, so long as it is properly constructed.

There are some rather atrocious error messages out there, but it'd be safe to say that there are more end users out there that don't read things carefully.

Yeah, and dogs salivate when you run the can opener. If you build a system that operant conditions people, you bloody well shouldn't expect them not to be conditioned, especially when they're just trying to get things done and don't care about using the computer at all. It is a tool, and a badly designed one in many ways.

Good, fast UI

Something that I learned in my UI design class was that when designing interfaces - the less risk there is associated with each action, the faster the UI will be to use.

So, exactly like you said, there's less risk in turning the key to your car if there's no chance that sometimes it will mean your car disappears. If there was that chance, you'd have to train yourself to check and doublecheck the state of your car before turning the key. This would slow you down quite a bit, and would be bad UI.

Instead of just deleting the car, the car's UI could confirm with you (similar to popping up a dialog) when it seemed like you were doing something that you might not want to. Or it could keep you from doing it altogether, although that would mean less capability.

However, a better solution is to make everything undoable, quickly and easily. In the case of deleting files, if you delete files, they are deleted. If you save over a file, the previous contents is gone. But if you want to bring them back, make it easy and always possible. For much of computing history, that wasn't really feasible, due to performance and storage constraints, so they opted for confirmation dialogs. But those technical limitations are much closer to being removed now, at least for simple interactions by untrained users. For those playing at home, see Apple's Time Machine [apple.com]. For more complex interactions, pushing the limits of the machines further, I imagine you'll still rely on better-trained users.

User Centered Not User Designed

RANT: Designing good, easy to use software is not as hard as many people to think, although writing it is harder than what most people do now. User's are not good at designing software, but only the user knows what they want to do and how they want to do it. This should be the beginning of the UI design. "What does the user need to do, and how can they do it most effectively." This should be almost completely divorced from how the program goes about providing the functionality. Usually, the UI should be up and running before the back end is really started. Most software today is designed the other way around. "We can make software that does this and this and this, now how can we let the user get to those features." The term "user centered" is in contrast to feature or engineering centered. Users should not be designing it, but you do need their input and testing to see what works and what doesn't. Follow the basic rules of UI development and you can miss many obvious problems, but at some point you need users to show you what you missed.

Most Users Just Want to Get On With the Job

I don't think the typical user wants to be bothered learning to use a piece of software, they are focused on the task they have to accomplish. If your software easily facilitates that task, with the minimal (preferably zero) learning curve, then they think its a good program, if it obfuscates that task, requires more extensive learning, or simply doesn't perform in the manner they expect it to, then its a bad program. Rightly so in most cases. Its only those in highly technical fields - or computer programmers etc - that usually need software with any real complex functionality. For those individuals, the cost of the learning curve (time and effort) is worthwhile if its more efficient that some other method of accomplishing some complex process or processes (time and effort).

Most programs seem to come with more bells and whistles than they need to, but then I guess they are trying to provide all the tools that I *might* be looking for in one package. I have never used more than about 10% of the features in any office suite for instance, mostly I just want to present a document containing well formatted text in the font I want.

The only place I appreciate complex software is in the areas where it suits my needs - a good IDE, Editor, graphic and sound manipulation software, and the Games I play. Outside of that most software is more hassle than its worth and I resent having to learn to use new programs just to achieve one tiny task.

I think the answer is coming in individual devices that serve specific functions and don't try to go beyond those functions. My cellphone has no camera, no email, no web-browser etc, but it does let me talk and receive calls. Thats all I need it to do. If I wanted the bells and whistles I woulda shelled out $350 Cdn for a Razor :P

I'm happy if it 'just works'

Most of my end-users are as well. We're unhappy with 'doesn't work' and especially with 'fails randomly, in interesting and unrepeatable ways'. Sure, most software sucks on some level. The users want it fast, cheap, and working (choose any two), the programmers (including me) want it to work excellently. The stuff that ships is a compromise between 'works' and 'insanely great', the level of compromise defined by budgeting and timelines.

Asking on Slashdot? Let the love-fest begin!

Users don't know what they want.

No frickin' kidding.

If you give users a choice between two mutually exclusive features, they will answer "yes". They will then complain at needing to pick one at runtime (or complain that you didn't include the other option, if you made the choice for them).

If you ask them if they need proveably-never-used features X, Y, and Z, they will vehemently insist they do. They will then complain that the final product confuses them with far too many features they don't need.

If you ask them how they want something to work, they will either A) Shrug their shoulders (then later complain you didn't listen to their input); B) lie to hide their own abusive behavior (then later complain that they can no longer get to their por - ahem - family photos); or C) Give a long, detailed explanation of what they (then ask what madman came up with how the final product works).



Should software 'just work', or are users too lazy?

Both. Software should do one task very, very well. If it doesn't try to manage photoalbums while doing your taxes and making coffee, it can perform its function well while not overwhelming the user with confusing options.

At the same time, users need to realize that computers have FAR more complexity of control than their car. In most states, to drive a car, you need to have reached a minimum age, pass certain tests of physical capability, take a six week training course and pass a written test on that material, and finally take an actual road test to prove you can handle a vehicle - And even after all that, you usually have only a probationary license until you've remained incident-free for a few years. Yet software should "just work"?

Where can I sign up to sue Chrysler over my car not automatically driving me to work (with an unannounced side trip to the grocery store) when I get in and turn on the wipers?

Garbage In, Garbage Out

I'm the lead software developer on critical carrier infrastructure software. I get vague market requirements, no spec, and despite repeated requests my company won't send me to customer sites to see how they use the software. Most input from the field is not forwarded to me. I deliver a product I'm reasonably proud of, but whether it's what customers want, I couldn't say. If it's not, don't blame me.

Good Design Means Not Needing To Choose

I think a perfect example is OS X. It just works for the users like my grandpa who want that but offers easy access to the command line and BSD parts for the technically inclined.

The key is good UI design, in particular good separation between advanced options and standard options. Windows fails because far too frequently a normal user needs to go access the advanced features so all the advanced features and terminology are there to confuse the user. Try sharing files in windows and you need to do arcane things like change the workgroup name. Just to check if I could uninstall programs I've needed to run msconfig. Conversely on a mac the normal user just deals with the preference pane and never has to run command line programs or the like.

I don't mean to be a mac zealot. They've done things wrong as well (I'm pretty pissed about their special power cord) but they did a good job of separating advanced from basic features, partially because they were willing to jettison the old ways of doing things.

In any case good design doesn't require a choice between power and ease of use. It just requires a clear cut distinction so the normal user never needs to deal with the advanced features.

false dichotomy

Where does your opinion lay? Should software 'just work', or are users too lazy?

These choices are a false dichotomy. It is possible to have products which just work and which allow users to access more advanced features (and rewards them for learning a little more about what they're trying to use). The UI principle [which should be] at work is called "progressive disclosure": don't overwhelm the user with stuff they need to know or complex steps they need to follow for basic tasks to be accomplished, but let them work their way up to it.

A good example is the UI of a well-designed VCR. Power-on and Play are big buttons right on the front, and the more complicated stuff is behind a flip panel. My non-/. parents don't want to program a Mars rover; they just want to put in the tape of their grandchildren and watch it. On the other hand, my wife who doesn't want Tivo programs complicated, recurring weekly recording schedules; and she took the time to learn how to do it, and has figured out which VCR you just hit Power-off and which VCR who have to hit Power-off and Timer together. And I just want to flip the panel and find some arrow buttons so that my parents' VCR isn't flashing 12:00 while I'm trying to visit with them.

If you want to do something more sophisticated, you need to expect to learn a little about the application you're using; and IMHO most reasonable people are willing and try to do so. But you should be able to just push Play without knowing which codec was used.

Perfect timing

This post couldn't have come at a more precipitous time. I work for an educational facility which uses a web-based "business portal" for all of our HR, Payroll, Purchasing, and Accounting functions. At this very moment, I am (pretending to be) entering data into this system. There are (on a guess) 100 fields that need to be filled. About 85 of them will always have the exact same data. Another 12 will be identical for every entry from the same order. Only 3 are unique--and one of those is the auto-increment primary key. It requires 3 mintues and 5 different forms to enter all this information. And all but 2 fields could automatically be captured by the system and applied to the form (right now, we're just reading it from one form and typing it by hand into another form). Now, this is a program that's supposed to improve the efficiency of the businesses that use it, however, it's laid out in ways that actively hamper the effective use of the software. This is a perfect example of a situation in which you absolutely want the users telling the programmers how to do things--not how to build the code, but how to design an interface that allows for smooth, efficient use of the tool. I run into the same situation in so many programs, and it really frustrates me. I think one of the reasons that Apple has become so successful in the various niche markets is because they put so much emphasis on creating a smooth interface between the users and the code. Most users don't care about the code. They care about how easy it is to accomplish what they want to accomplish. There's no reason that a program can't both be properly-coded and "just work". The two are not incompatible.

Conspiracy of Toonses

A few reasons that software sucks:

1. Programmers don't really understand users' domain,
2. Users don't really understand programmers' domain,
3. Users don't really even understand their own domain, and finally
4. Programmers don't really understand their own domain either.

The first two are obvious enough, and programmers eventually see instances of the third. As for the fourth, most programmers do not even know of the critical insights of the field (e.g., The Mythical Man-Month, Dijkstra's essays), let alone accept them (or knowledgeably deny them).

A problem of interface

Several slashdotters have already pointed out why the car analogies that (apparently) pop up in the article as well as in the comments fail. Ultimately, a comparison between computers and "real-world" devices fails because of interface.

To start a car, you turn the key clockwise. To open a new file, you click with the mouse.
To stop a car, you push the brake pedal. To save a file, you click with the mouse.
To turn a car off, you turn the key counter-clockwise. To delete a file, you click with the mouse.

A significant factor in the difficulty of software use is that when we speak of "interfaces" we are almost always thinking one level lower than we should be - that is, no matter how nice and clean and useful your GUI is, the real interface for ~90% of software users is the mouse, keyboard, and monitor, regardless of what is displayed on it. In a car, turning the car on or off is an entirely different motion than making a right turn, which is different from putting on the brakes, which is different from putting down a window. We also have years of experience riding in cars and watching parents drive as children to teach us that "when Daddy does X, Y happens."

Computers are fundamentally different. Using only a mouse and keyboard and looking at a monitor is for all intents and purposes the only way to interact with the computer. Watching others use it to learn doesn't work nearly as well because the movements involved are much more precise, less varied, and their effects vary greatly depending on what state the computer is in: moving the mouse in a word processor moves the pointer around, while in Quake it'll change your view of your in-game surroundings.

Encouraging software makers to adhere to user-interface models helps a lot -- once the users are familiar with the model. Our current practices are inconsistent at best - the "desktop" metaphor exists only at the most basic level; once an application is open there is generally a half graphical, half menu-driven approach. From what I've seen, I think the Ribbon interface in Office 2k7 is an improvement, albeit an incremental one. I don't pretend to have a good model that will help ease-of-use, but I think the problem is on the decline anyway.

Those of us who grew up with computers do not have issues with the mouse/keyboard interface; we are familiar with it and the software models underneath. I have a feeling that as younger generations join the workforce, the interface problem will disappear or at least be greatly reduced. As long as some consistent GUI guidelines are followed, I believe that the metric for "ease-of-use" will evolve so that more complexity and control can be folded into the software without complaints from the users.

Re:Software. Not currently Science or Engineering.

It is, in some cases. Many universities now offer degrees in Software Engineering.

I'm a developer, not an engineer. To me, that means that I don't follow any formal methodology, don't belong to the local professional engineering organization, and don't necessarily have a degree. My style is more based on what I learned in my High School English courses than anything else, and is largely the result of many years of experimentation.

That description is the reason you either want or don't want a Software Engineer. Engineering is a slower process. It is rigorous and formal and based on mathematics. The results can be exactly duplicated, even if you have entirely different engineers working on it. When I write software, I do what many people call "hacking". Often, I write only the documents that are required to firmly establish the concept in my mind, then just keep writing and debugging code until it works. For many applications, I will write software that is equally robust in less time. That's because you don't need an engineer to design a blogging application.

Software Engineering is used in much larger, mission-critical applications, like a financial institution's transaction processor, or a real-time monitoring system, etc. Mistakes cost millions of dollars or even lives, so every possible scenario needs to be considered up front (BDUF). Hacking isn't like engineering, and that's one process of producing software. Software Engineering is exactly like engineering and that's another process of producing software.

mandelbr0t