Users Are Smarter Than Programmers

Who isn't? Managers. (Of course, it should be noted that throughout this page is the premise that InteractionDesigners--referring to a subset of programmers that the original poster chooses to identify with--are smarter than both "mere" programmers, and users.)

Proposed reasons why:

Users know that software is infinitely malleable and so it should serve the needs of users instead of vice versa (this is the point of InteractionDesign). So do truly good programmers.
Users know that you shouldn't live your entire life inside of a computer.
Users know that all current OSes suck, without exception. In my experience, many users think Windows is the exception. Hmmm. perhaps they are disproving this page :)
- Actually Macintosh owners have always thought that Macs rule, and that Windows sucks. So Mac users don't think all current OSes suck.
Users know that time spent getting your computer running, configured and administered is all a giant waste of time.
Users know EverythingIsRelative, programmers deal with BlackAndWhite and are thus less able to MakeRoomForAllViewpoints.
Related to the above, Users are skilled in RelationshipManagement, whereas most programmers see everything, relationships included, as objects SetInStone.
Users know that programmers are not their best friends so they need to take steps (ie, have an, as yet hypothetical, system with real security) to protect themselves from programmers. (The part about users knowing this is probably in the realm of wishful thinking.) In contrast, programmers are dumb because they think that they are the user's best friend. (Probably closer to parents who become upset when the children seek independence from them. After all, what do the users really know?)

Consider also: 'to kill' is to reduce someone's lifespan. By forcing users to waste time on configuring their OS, a system programmer is killing millions of users a little at a time. Maybe if users weren't so much at the mercy of programmers, they'd think programmers were evil ... I certainly don't know why they put up with the inferior quality and horrible service that characterizes the software industry.

Users put up with inferior quality because even bad software can be easier than doing things by hand. Usually.

How about renaming this topic to "users have perspectives that programmers lack" or the like? The existing title is silly and perhaps offensive.

No way. I have a better idea. Since the users are so much smarter, they should just write the software themselves.

{They often know much more about the domain than a outside software engineer. The trick is to leverage that knowledge without permitting them to derail stuff that they probably shouldn't muck with. It's not always easy.}

But, programmers are users too: you want your development tools to get the job done with a minimum of fiddling. Time spent configuring your editor, your IDE, your JIT, your run-time libraries, your version control system or your workstation is time wasted - time you could have spent developing. Every frustration you've ever felt with a particular tool or language is similar to what users have to put up with when they run your stuff. You are a user too, if you but knew it.

without the 'Especially unix....' sillyness (now snipped), the above list is pretty good :)

Gee, I thought the point of InteractionDesign is that interaction designers are smarter than users, programmers, managers, and... well pretty much everyone. Too harsh?

Nahhh, that's pretty accurate. Just outside the scope of this page.

So, why people buy computers and softwares ? masochism ?

That theory also explains the popularity of the PC over the Mac.

Remember that for a certain generation, the first use of a computer happens at work, meaning it's likely to be a Windows box. Then when they buy a computer for home, they're likely to buy what they're familiar with. Then their kids do their homework on it, so that's what they learn, too.

People also like having choices. The PC offers choices, software, and especially, hardware choices, that the Mac doesn't. That's why automobiles, from the same manufacturer even, come in different models. Had Apple licensed it's technology to others to produce, it may have had a fighting chance. to compete.

I agree that "first exposure helps", but that doesn't explain the first-time buyers who have never used a computer before. IMO the reason the PC is so popular is its ubiquity. And 20 years ago, it would have been the popularity of the Commodore 64. PITA though it was, it led users to dream of a fully-fledged PC. The die was cast way back then......... rs

Programmers can often identify conflicts and inconsistency that users just don't want to face. They may have to face such issues one way or another in the longer run, but programmers tend to be carriers of bad news at a pace faster than users may want to hear it. Examples in JustMakeItRight.

Programmers frequently use this as an excuse to do whatever they want. The expediency, laziness and arrogance of the programmer are seen by many programmers as legitimate issues which legitimately conflict with the users' real needs. Of course, a programmer will never say "I can't do that because I'm lazy, ignorant and arrogant." Rather, they'll say that there are "technical reasons" why something can't be done. They'll even gladly pour on the technobabble. And the more experienced the programmer, the more technobabble they'll be able to pour on.

[I'll disagree too. There may well be programmers for whom this is the case, but they certainly are not the common case or even a signifigant minority. Whats viewed as "laziness" by the impatient and unattentive user is usually an outside contraint, often placed by that same customer. Users never want to hear the reasons why something can't be done, especially if the reason it can't be done is conflicting requirements. I'm speaking broadly here, of course - most users are sensible folks - but they still feel that their legitmate needs aren't being addressed. The fact that these needs, while legitimate, are contradictory is of no concern. For the same reasons that a programmer may have trouble spelling out constraits to a user - ie, he's so familiar with things that it doesn't occur to him to make them explicit - users often fail to identify needs up front. We had to do a nasty last-second kludge in an app once because the users, at the last second, revealed the need to audit delivery dates. We didn't track those, there was no UI or sytemic provision for doing so, and the process as designed didn't have a spot for it. Nobody told us there was a need for that - but when mentioned, at the last second, *every single one* of our user representatives nodded and agreed that yeah, they did need that. Of course they needed that, how could they not?]

I'd disagree with the previous point. That type of programmer is a charlatan, using rhetoric to divert attention away from them being bad-programmers. Larry Wall once reputedly said: "The three attributes of a programmer are; impatience, laziness and hubris". He didn't mean that hackers sit around in front of the TV or wasting their time, that they're too impatient to sit down and take some time to do anything, or so hubristic that they can't listen to other ideas. All three of these attributes have negative connotations, but all are meant in a positive way. Hackers are impatient as they don't want to hang around wasting time when they could be solving the "real" problem. They don't want to be jumping through pointless political hoops before they can get to real work. They are lazy because they don't want to have to type in the same command 50 times with small variance in the command - they write a script to do it for them. This script is by far the better solution, not only saving time now, but saving time in the future and expanding the hackers experience and knowledge. Hackers are hubristic not because they think their ideas are the best, or they can do anything. Far from it, hackers are very often very deferential to other, more senior hackers, and very often use other "good" solutions as part of their own. You need to have some sort of hubris to actually start a bit of work in the first place. Without hubris, the Linux kernel probably would never have been started.

A computer must do what a user wants - otherwise it's largely pointless.

As a counterpoint, users often don't want to examine their processes to tell the programmer what to develop. They say "I just want to be able to do X", when X is a nebulous, variable activity. Then when the programmer asks during development "Does doing X require doing Y?" the user says "Don't bother me with the details! You're supposed to be so smart; you figure it out!". When the product is delivered, the user then wails that it does Y, which they didn't want it to do. From the developer's perspective, they appear to expect one to read minds.

JustIsaDangerousWord.

I've learned to create dummy samples when they are fuzzy about needs. It does not stop all mind-changing, but catches much.

I'm sorry, but if X is nebulous and variable, commiting to fulfill the need is declaring out loud that you understood the need of the client. I'd say that you should run away. Or dig deeper. If users don't examine their process, why not do it yourself? Why not simply ask them "Then, to do X, what do you usually do?". -- LLR

One doesn't always have the luxury of picking and choosing projects/clients/customers. For example, if you work for a given company, you are expected to work on whatever project the company asks you to. Voice your opinion to your boss(es) if you see danger ahead, but ultimately your boss(es) decide which tunnels to drive the train into, not you. (Practice good CYA if you spot risk.) Dealing with difficult customers is just a fact of life for most in this business. HumansSuck.