Apply today for a FREE subscription to CIO Magazine!
Wed, Dec 26, 2007 13:15 EST

|
Posted by: Esther Schindler in Rants Topic: DevelopmentBlog: Developer Wisdom
Current Rating: |
Awful as they are, these application design errors — all the fault of lazy developers — are entirely too common.
I lived in Buckminster Fuller's summer house for a year, not long after the brilliant old man died. His grandkids hadn't really cleaned it out; the furnished house (built in 1762 as a Captain's House overlookiing the Penobscot Bay) still had his personal library, a spare pair of eyeglasses, boxes with gifts received as a visiting dignitary (such as a rikshaw in the root cellar). I learned to love Bucky, and not leastways because of his inventions and writing.
Among the tiny watts of enlightenment Buckminster Fuller shared was the wonderful concept of dymaxion, a holistic view of energy use. It's generally defined as "world-energy efficient," or "that odd three-wheeled car Buckminster Fuller designed in the '30s or '40s," but in fact the term encompasses much more. One example that I remember is the notion of a bank "saving money" by hiring fewer tellers despite a brisk lunchtime business. Bucky pointed out that hours of human creativity and production (most of which would be invested in that bank) were wasted by customers stuck in line. So the bank was wasting energy in the name of saving it. (I was so impressed that when a kitten acquired us that year, we named him Dymaxion; that was a huge mistake, as cats don't care about being energy-efficient. And Max was as dumb as a box of rocks.)
Bucky's philosophy had a big impact on me. Ever since, I am particularly irked when I see someone take a "shortcut" that saves that individual a couple of minutes, but thereafter causes extra effort from every single user. Nowhere is that more obvious than in these all-too-common errors in software design (non-)usability.
Making the User Do Something the Computer's Better At
It's happened at least a half-dozen times in the last week. I go to join an online community, or I make an online purchase, or I login to a financial site. I'm asked to type in my SSN, or my phone number, or a credit card number. But the site doesn't accept my input if my SSN has dashes, if the phone number includes parentheses, if the credit card number has spaces. Why? Why? Typing in one long string of numbers, sans spaces, is error-prone for any user and even harder to read back; why make him try? When the computer is far better at tasks like this?
It's because a developer got lazy. The algorithms to strip out formatting codes have been around since the days when COBOL dominated the earth. All it takes for a program to evaluate a credit card data entry field is to strip out anything that isn't numeric digits, make sure it has the proper number of characters, and... well, that's all there is to it. This is only a few lines of code.
Sure, developers don't want to write any more code than they have to, because it has to be debugged, tested and supported. Yet, like the people queued up in Bucky's bank example, the programming team's momentary time-savings has a long-term cost in user time and frustration.
Losing Context
This one is a little harder to explain, because by definition it's about optimizing a user task that has several steps.
Let's say that you're cleaning out or organizing a database. It doesn't matter what: it could be a list of the hundreds of books in inventory, or blog comments, or a to-do list shared
In many cases, it is hardly the fault of the "lazy programmer". I recently had a conversation with someone (project manager): she was explaining how the Help Desk is complaining because the application developers aren't addressing the known issues with this particular application. I said that I see there are a number of errors that have been reported by the users, would she like me to start working on them; she said no, the new features for another system are more important, that we'll fix those later. These errors haven't been fixed for over a year, and they probably never will be.
There is an assumption by end users, that their needs matter to everyone, they don't. They matter to them, and they matter to the developers, who often enjoy the satisfaction of helping people get their work done. But the end users are often on the bottom of the list of priorities when it comes to everyone else in the company. If the COO wants a new feature in application X, and users are having problems with application Y, who do you think is going to get the developer's limited time?
The C-Level people may say that the users/customers are priority number 1, but there is a saying, "don't tell me your priorities, show me your budget and I'll tell you what your priorities are." When looking at the budget of most companies, you'll see how very little money is allocated to address user issues.
As for sitting down with end users: yeah, as a developer that would be great; it would make the application much better for the users, and make my job so much easier. Sadly, this rarely happens. Software is expensive, and the people who pay for it (C level executives) like to be intimately involved in every detail if its creation. Even though they've never used the old software they are replacing, and they will never use the new software we are creating, they will insist on making all the decisions on how it works. I always ask for real end user's input, which sometimes I get, but most of the time I don't. Sometimes I'm actually instructed not to talk to them, for political reasons.
Give developers some credit, they want to be successful, to feel like there work matters to those who use it. So often, especially is politically motivated large corporations, one road block after the next is place in front of them. Some companies do it right, but they are rare (and often successful).
It isn't always your fault. But in the end, it's your responsibility. Even in the face of bad politics and poor priority-setting.
In Five Things IT Managers Should Know About Software Requirements, a whole section goes into the carpet-yanking phenomena, including:
You can be part of the problem, too. Geoffrey Slinker, a software developer for more than 20 years, says he is most irked by the tendency for a software feature mentioned or proposed by the CIO, or any CXO, to instantly become a required feature. "The problem doesn’t lie in the proposed feature," he says. "Often, the feature is a good idea. The problem lies in the disruption that is caused. The proposed feature becomes a high priority just because a CXO made the proposal. ... Even if the statement is an off-the-cuff comment during a demonstration towards the end of the development cycle, the statement can be interpreted as an action item and cause a chain reaction of meetings, changes and re-prioritizations." Remember that your voice carries, Slinker cautions; don’t let your position disrupt the prioritization of software requirements.
One issue, of course, is how much independence you have in defining how the code solves the problem. You aren't "done" the moment that you convince a field to collect data, without regard to data quality? They wouldn't say you're "done" if the field permitted alpha characters in a numeric field; why are you "done" if it's less-than-usable either?
I'm not claiming the answers are easy, especially when a ship date is looming. But just as the difference between a hack writer and a true author is editing, and the difference between a weekend carpenter and a craftsperson is her finish work (yes, you do need another coat of tung oil)... a developer isn't done when the code works; she's done when the code works right.—Esther
I'm sorry but, while I appreciate the craftsman analogy, your implication that a good developer is one who takes up the slack (at personal expense) in an otherwise potentially broken process is not very appropriate when viewed from the CIO perspective. If that's not your intent, what is? The implication that there are unskilled developers in the world? A developer gets paid to create a solution within the confines of available resources (they do not, usually define these resources). A developer that strives for that "last coat of tung oil" in the wrong environment won't have a job. Sure there are weak developers who don't know the difference but if the management hierarchy doesn't know or care about usability, implying a good developer should suck it up anyway is disingenuous.
The whole process needs to be skilled, intelligent and flexible. Providing a CIO with a new set of random benchmarks with which to measure their staff, without explaining their complicity in the process is not doing anyone any favors.
chris
I think you've set the wrong expectations. As a CIO, I'm not involved in the coding aspects of projects. There are far too many efforts across the enterprise for me to do that. I am responsible for setting and managing the expectations of the business units, project managers, and technical staff regarding both their performance and available resources.
If you're not raising the bar for the expected performance of your developers, then you've missed a large part of the role of the CIO. Most of this article, and the managers or executives I've dealt with, expect usability. What Ester has stated in this article is exactly that: raise the bar. When was the last time you went to a webpage that said "under construction"? In this era of internet ubiquity, that's unacceptable. Society's expectations have changed. There is no reason for developers not to take these best practices into account when building applications.
My favorite sin to hate is when a dialog pops up with three distinct options, but the developer used a standard "Yes, No, Cancel" dialog. There is typically a whole bunch of text explananing which button takes which action, like "Press YES to do action A. Press NO to do action B. Press cancel to action C. This sin is committed too often.
Take the time to build a dialog that fits the real need and uses English verbs on the buttons, such as "Save", "Discard", "Exit", "Use xyz", "Start", "Check Now", etc. Radio buttons are good too, then the buttons can simply be "Ok" and "Cancel".