If You're Going To Blame The Programmer For Not Being A User, Why Not Make The User A Programmer?
from the simplicity-isn't-simple dept
Reuters is running an odd sort of article today that basically says that complex and difficult-to-use software is all because programmers aren’t normal users, don’t think like normal users, don’t design like normal users and basically muck up all kinds of software by making it too complex. While that sounds like a nice theory, it’s unfortunately not true. Certainly programmers not understanding users is one element of trouble in the system. Just today, in fact, I was involved in a discussion here over a certain feature in our own offering that I felt wasn’t sufficiently designed for certain types of users — at which point came the obvious pushback: why hadn’t I explained that potential usage to the programmers in the first place? Indeed, part of the fault was on my end for not detailing enough how the feature could be used. However, this also highlights another thing that’s wrong with the complaints in the article: it focuses on how programmers make things too complex, but the problem in this particular case was that the programmers had simplified things to the point that it wouldn’t be useful in certain important use cases.
As we were recently discussing, the focus on “simplicity” is absolutely wrong. It implies the wrong thing. People want a product to be simple to use, but they want it flexible enough to be used in many different ways — and those may be quite different for different people. And, that’s where things get tricky. It’s not just that programmers think differently than users, or that marketing folks can’t explain clearly how a product will be used, but that it’s nearly impossible to figure out how a product will really be used by users until they’re actually using it. At that point, you want the flexibility to add in certain tools or features that become more obvious — but may only be obvious to certain subsegments of the user population. At the same time, you don’t want any of this to overwhelm those who are using the product for a different purpose.
What will be most interesting is to see what happens as situated software products start hitting the market, with the idea that the users can make their own damn programs — avoiding the disconnect altogether. While it sounds tempting, it also seems likely that complexity would actually increase, because each user has very different features and requirements — and they’re not designing the product for overall usability, but for their own satisfaction. In that case, much like the officeworker who keeps a ridiculously messy desk (which, yes, includes me) but knows exactly where everything is, complexity actually works for that person. So, rather than blaming programmers for not making software simplistic enough, perhaps programmers should start handing over the design tools to users, and then laughing hysterically at the not-so-simple products that come out of it.
Comments on “If You're Going To Blame The Programmer For Not Being A User, Why Not Make The User A Programmer?”
Telephone and SSN text boxes
Just today I was trying to paste in a SSN# from our database into a form on a browser. Our format is xxx-xx-xxxx but the programmer only allowed enough room for xxxxxxxxxx. When I pasted it, it cut the last two digits off because the text field only allows nine spaces and the dashes took up two spaces. I then proceded to call the programmer names in my head because of this. Now call this petty but how hard would it to have allowed both forms or to automatically convert one format into the one that is required by their database.
Flame on.
Re: Telephone and SSN text boxes
Was it part of the requirements to accept dashes? Sometimes programmers have to many things on their plate that they overlook simple things like this.
Re: Telephone and SSN text boxes
This opens the door to boundless evil. It can try to convert different formats until it sees one that doesnt work. Then once people come to rely on it, it will fail and nobody will know why. There is value in things operating predictably, even if it is not predictably exactly how you would like. Reliable things can be built upon and increase productivity even while irritating you (be honest, something will irritate you–its just a question of what.) Unreliable things we can only hope will stand up under the weight until they get replaced. You can pattern your life around the simple known, but not the unpredictable, complex unknown.
Also if you ask how hard it is–probably harder than slapping together the whole data entry screen. Sanitizing user input is not easy and programmers hate to do it unless theyre the sort that love to do it.
Re: Telephone and SSN text boxes
One thing I have learned from my years of programming, “They always make a smarter dummy!”
YOU JERK!!!
Requirements
Requirements gathering is the hardest part of the Software Development Lifecycle. Any developer new or seasoned will be able to tell you this.
But I believe that it is both the business and the developers job to gather requirments to gain a good project definition.
i.e.
The business may say, I want a blue dog with yellow stripes.
It’s the developers responsibility to start asking questions at that point and ask what breed, how long of hair, snout length etc.
The business comes back with their answers and maybe some more suggestions and then the developers go back again and refine the product again. Eventually when the business and the developers gain a mutual understanding of what they want they can begin the project.
Unfortuanetly due to resource constraints, people constraints, or time to market issues this beautiful dialogue either doesn’t happen or is shortened.
This is why user’s aren’t getting what they wanted, it’s not just the programmers fault.
As a programmer...
I’ve been a programmer for over a decade (God I feel old!) and I can see the general jist of the reuters article, but I think your analysis of the true root of the problem is correct Mike.
However, I don’t think it’s as easy as designing easy to use software that’s invariable extensible and flexible. As a coder I can tell you that the main problems are no matter what features we put in someone will always say “not enough” and whatever ones we take out someone will always say “too rigid”.
I think that having highly configurable code sounds like a great thing, but when you actually try to do it you realize you just made something so incredibly complex to learn that that configurability gets lost to the frustrated user. My hat off to the first team that comes up with a highly configurable interface that doesn’ confuse the “average” user to high hell.
So what’s the solution? Well, I’ve always believed that interopability between software is important. Standardized file formats, easy OLE like sharing, that sort of thing. Along with that, a bunch of cheap software solutions that do less than current things (for instance MS word does way more than a word processor needs to do). Basically what I am proposing is for users to be able to pick out a bunch of “simple” apps that when combined by shared formats and data sharing, can address the custom needs of the user. For instance, if your company does a lot of bulk mailing why not have a simple word processor working with a database program and finally a bulk mail program (something that can be done by a single app like Word today, but a lot of people have trouble learning how this is done or maintaining it). My basic hypothesis is that it would be easier for average users to learn a bunch of simple applications that do various things than one or two “complex” applications that do everything.
Just a thought.
OSS == flexible HCI
“People want a product to be simple to use, but they want it flexible enough to be used in many different ways — and those may be quite different for different people”
This is a tough tradeoff. There is of course an entire branch of computer science called HCI, I myself took a 3rd year option in the
last semester many years ago, it was mostly psychology and complexity analysis. During the software lifecycle, following the strictest interpretations of Taguchi and Sommerville this should be in right from the start – you could say that the software is written top down and bottom up simultaneously *from* the spec of the user interface and the user task model. But this rarely happens in practice, not in real SE where the UI is often bolted on at the end as an afterthought and simplification is actually nothing more than hiding underlying complexity.
“but that it’s nearly impossible to figure out how a product will really be used by users until they’re actually using it.”
Structured observation is another fine academic idea that never really happens in reality, at least not in my experience of development. This is where open source really pays off because the
lifecycle iterates over incremental improvements – possibly the best practical solution, so long as bugtracker and CVS are used properly and people actually file bug/desire reports.
“the idea that the users can make their own damn programs — avoiding the disconnect altogether. While it sounds tempting, it also seems likely that complexity would actually increase, because each user has very different features and requirements”
Indeed, this is the strength and terrible weakness of open source too. We end up with a thousand “correct” but personal takes on the best way to wrap it up. The interface ceases to be a common, shared view once everybody has customised their own code into something unique and inaccessible to everyone else. Look at the problem with the sheer number of Linux distros alone.
“So, rather than blaming programmers for not making software simplistic enough, perhaps programmers should start handing over the design tools to users, and then laughing hysterically at the not-so-simple products that come out of it.”
Imho, that is what we already have with OSS. The tools are already in the hands of the users, who happen to be part-time developers too. And much of the messy, unmaintainable software we see on Sourceforge is the very result you describe. However, it’s not all write only code, for every 10 bad programs one or two emerge that are elegant, flexible and have longevity. It’s just a very inefficient process to get there. Comittees have never been much cop compared to a visionary dictator, but they can and occasionaly do yield the optimal result.
Dilbert is very real
Putting the blame on the programmers is the same as blaming the printer for a failed marketing campaign. Fault lies with the all too common IT managers, pushing the same failed methods of project management over and over again. Somewhere along the line people began to believe the problem was poor requirements, and if we spend more time, effort, money, etc writing requirements documents it will solve the problems. And when it doesn’t? Was it in the requirements? No? Well there is *your* problem.
Programmers get performance evals based on the number of features they complete, and the number of bugs they caused. After a while, you learn it’s not good to risk a feature not in the requirements because it doesn’t count and can only hurt your review and chance of a raise. Also, if the feature is dumb, changing it is a world of red tape. Apathy is high in this career field.
In the Art of War, Sun Zu said if the troops screw up, then the general needs to make sure his orders were clear. If they still screw up, it’s time to replace the officers. Blame sits with management.
Immune to Criticism?
Have you ever criticized a movie? Well, let’s see YOU make one! Or a TV show…or art…or a fine meal. Programmers are no more immune to criticism, regardless of how much it may sting. Nor are designers, managers, etc.
Constructive criticism, of course, is they key. And yes, over-generalized blanket statements (“simpler is always better”) never help.
(Irony Detector: the use of hyperbole — the “never” above — renders the sentence itself as an over-generalized blanket statement.)
methodologies
“Requirements gathering is the hardest part of the Software Development Lifecycle.”
I salute you Tully, few more truthfull words were spoken.
I always take an old school aproach and split this into systems analysis, req spec, and formal spec. The best guy to send to the client first off is your non-programmer, taking a high level view and talking on the same terms as the client. Then he sits down with the team to req spec and out come the markers for the whiteboard, the Z and VDM charts, the ER models, the workflows, and all that stuff. Then it has to back to the client as a plain english spec while the programmers take the formal spec and start to spec out objects and data. It’s the HARDEST part by a long way, but I firmly believe that every project lives or dies by what happens in those first weeks.
“Basically what I am proposing is for users to be able to pick out a bunch of “simple” apps that when combined by shared formats and data sharing, can address the custom needs of the user”
At the risk of really sounding old Tyshaun, that is called the “Unix philosophy”. It’s just never translated well from the command line into the GUI windowed environment.
“There is value in things operating predictably, even if it is not predictably exactly how you would like. Reliable things can be built upon and increase productivity even while irritating you (be honest, something will irritate you–its just a question of what.)”
Imho the best compromise for non-safety critical code is Python, particularly the way content management systems like Zope combined with Twisted can hide typing so well that you never even have to think about your data formats and everything gets coerced nicely into the right type like magic.
Programmers are not the Designers
A programmers job is to develop something that is stable/usable and meets the design requirements; not decide what stability/usability means or what these requirements are. Those are for QA and project leads respectively.
If I had to pick one group to be responsible for the issue w/the SSN field that only accepted 9 characters I would have to say QA. However, if they were going off of design documents only (typically how outsourced or lowly QA firms/groups work), then I would blame the project lead.
However, I’m going to guess that the QA was done by people who did little more than make sure round pegs fit into round holes. A good QA person should have realized that if you can only paste 9 characters that are not all numeric into a field limited to 9 characters, its a bug. They should have limited the field length to 9 numerics or stripped the dashes.
Info Architects and UI Designers
All this article says to me, as a technical writer working on software apps, is that developers shouldn’t be doing design work, professional designers should.
If an app was coded to a well-designed UI rather than imposing a UI on features and functions, the developer would not have to worry about whether or not to accept dashes, but instead implement to the design. One developer has one perspective, and therefore makes decisions based on personal experience, “How would I want this to work?” It’s a different mind set to consider “In what ways would noobs want this to work, and could there be a basic and advanced method for it?” That’s not efficient when tracking metrics for one’s performance review.
Let coders code, and if someone is to be blamed it would be the higher level managers and execs for poor staffing, assigning of priorities, and delusion beliefs that there is no skill or talent required to produce usable and intuitive UI.
Heck, I worked at one large company where they replaced a technical writer with a developer because the developers could create “good enough” docs. Perhaps true if the only audience was their internal peers.
The lack of simplicity in the product would be a direct result of lack of “user” perspective. It’s easy to assume everyone knows the little short cuts and or knows how to do common tasks, and it is far too easy to skip over accommodating for them in the UI.
I have also heard big ego developers intentionally not make things simple because they basically believed that anyone not smart enough to figure “that” out probably shouldn’t be using the product anyway…
The gist of the article is correct, but the blame should be on not hiring a designer and architect rather than on the developers on the project.
It is the role of programmers, as people who basically spend all day thinking logically and codifying it, to give and tell the users and project managers what is logical. If the result may be complex if the underlying concept is complex. Simple implementations of complex problem solving are always wrong. This large area in the middle accounts for much complexity. The remainder comes from bad programmers, and bad programmers being forced to do illogical things.
Government is part of the problem
With all the fingers I have seen in this article pointing blame, one finger that is missing is the government.
I am an in-house developer of accounting software for a large manufacturing company. I handle both the development and supoort. However, because of the Sarbanes-Oxley Act, I am unable to use the software that i have programmed and am expected to support.
It’s not that I don’t think like my users, it’s that I can only understand as far as they tell me. If I was legally aable to actually spend a day in their shoes to understand their needs, i would. However, the government does not allow it. 9 times out of 10 it is neither the developer’s or the user’s fault that the software is not perfect, it is the outside forces.
Re: Government is part of the problem
“I am an in-house developer of accounting software for a large manufacturing company. I handle both the development and supoort. However, because of the Sarbanes-Oxley Act, I am unable to use the software that i have programmed and am expected to support.”
That is bizzare and unworkable. Very interesting. How does SOX stop you from testing your own code?
Frankly, if I were put in that situation I would laugh at them and walk out the door. It’s a completely impossible position.
SSN's, Programmers ETC
SSN’s have two formats that are typically used xxx-xx-xxxx and xxxxxxxxx. How hard is it to allow both kinds? Not very. But at what cost? More lines of code, a larger executable, or slightly longer file bloat for download (Web Apps). Now how about phone numbers? The possibilities are (xxx)-xxx-xxxx, (xxx) xxx xxxx, xxx.xxx.xxx, ad nauseum.
And what about country codes for international numbers?
It is the responsibility of the user to notify the designers/programmers/analysts what they want. Does this happen in the real world. Not always. A programmer, maybe the analyst and designer, will code what he thinks the project lead is requesting, and then it goes back and forth until it goes to the customer as a final or beta product. At this point the ball falls back into the user or customers court to further define any missing pieces (Such as being able to accept 9 different phone formats be damned the code length)
This whole conversation is analagous to blaming a doctor for not trying to treat pneumonia instantly when all the patient states is they have the sniffles. A GREAT doctor will notice other symptoms and try and coax more information from the patient. A GREAT patient will also be more forth coming with their issues to help the doctor better perform his/her diagnosis. A failure in either part can lead to issues
The usual stupidity
Reading the article just reminded why everyone who is not technical should just shut up about programming. The underlying idea is that programming is mundane work, so why not just automate it and let the user do it. Which all of us who program know is totally untrue.
I’ve worked as a straight code hound, and I’ve worked as a designer. I do agree programmers are not responsible for the design, although if you work in a small shop you may end up in that role eventually.
Doesn’t this article just make you apprecaite other people, like home builders, car makers, authors etc. etc. Seems like there are critics for everyone who is creative. My philosphy is, if they are so smart, let them create some C libraries, java, or Data warehouse algorithms in Oracle since it so easy and quit complaining.
The UI must come FIRST
One big problem is that most all software is designed from the bottom-up. Users use it from the top-down.
Even if you “think” you’re doing top-down design, face it: You’re writing base classes, and DB wrappers, and logger methods, long before ever touching the UI.
Then – oh crap, you’re running behind – better throw the UI together.
Next time, try coding the UI first. Try using mockups, hardcoded pages, stubs, etc. They teach you that in school, but it’s seldom used in reality.
Also pad a factor of 2x in your time estimates. Most programmers drastically underestimate their own schedules…
Telephone and SSN text boxes
Why not just delete non-digits? If in TCL you have
x = “(xxx)-xxx xxxx”
then ‘regsub -all {()- } $x “” x’ gives:
x = “xxxxxxxxxx”
This is triival to program and easy for a user to cut and paste with a value containing non-numeric characters. Are programmers lazy? Or are they told that they must conform to rigid requirements that are nasty to some common ways that people want to do things?
Usability testing
One step that nobody mentioned yet is usability testing – with actual users. It can be done cheaply, and should be done at many stages of development.
I recommend Jakob Nielsen’s web site:
http://www.useit.com/
and this article
http://www.useit.com/alertbox/fast-methods.html
Ehhh.. you know, it’s at once a terrible idea and an excellent idea. I mean, within certain domains, you already have this sort of thing, and I mean, everyone knows about VBA.
I don’t think it’ll really make life much easier for anyone though, user or programmer.
Goddamn!
I’m printing this article and sticking it on my office door.
Excel as user programmability
I think folks miss the fact that this is already happening, and even done well. In Excel.
Making users programmers is exactly what makes Excel so powerful. In many circles it has become the de facto management knowledge tool. And while it lets you use VB, the power of Excel is largely in its ability for users to put statements like “=sum(a1:a4)” into cells.
That is user programming at its finest. The point, imo, is to give users software that lets them simply discover and create as much functionality as they need–and no more than they have to–within that use context.
Do that well, and you’ll find people using your software for things you never dreamed of.