DIY optimize

Insights from a book on why software s**ks

For those of you who wonder why software is so difficult to use,

may I suggest the book Why Software Sucks, by David S. Platt (note: I normally avoid such words, and give the title in its entirety here only out of a desire to be accurate). In

fact, I was reminded of this book by a Tech Republic link, even

though I had heard about it before. I mention this book

because it offers insights into and can help improve your

relationships with your customers.

In an early chapter of the book, Professor Platt discusses a

theory that explains bad software. He concludes, not

surprisingly, that developers focus on their own view of how

software should work, rather than considering how users believe it

should work. As an example, he cites the floating toolbar feature

of Microsoft Office. How often, he asks, do people who use Word,

Excel or PowerPoint really use that feature? Or, put another way,

when they DO use that feature, how often does it happen by design

rather than by accident?

Curious about and intrigued by this theory, I decided to check for

myself. At a customer service training program I conducted last

week for IT professionals at an East Coast university, I polled the attendees, asking them this same question. I found, not surprisingly, that only a small percentage of them floated the toolbar because they really wanted or needed to. More commonly, they did so by accident.

I then asked if what they said, when they accidentally floated the toolbar, was printable, and everyone laughed.

Think about this "floating toolbar" matter yourself, and ask if you also do so mostly only accidentally. Now think more about whether, instead of putting in that feature, the developers should have spent time and budget to put in things you REALLY would find useful.

Avoid giving your own customers the same grounds to be annoyed at you. The more you show customers that you understand their point of view, the greater (generally) will be their satisfaction. When dealing with a customer, remember that the technical problem will cause an emotional reaction. Depending on the circumstances of the problem, and the work affected, that reaction could range from mere annoyance to outright panic and anger. For that reason, if you want a satisfied customer, you probably need to do more than solve the technical problem. You may need to be the counselor/psychologist as well, and let the customer know your awareness of the customer's emotional reactions. When you do so, even if you don't solve the problem right away or get it completely right, the customer is more likely to "cut you some slack." On the other hand, if all you do is solve the technical problem, you may leave behind a customer who STILL is upset at IT.

I hope this insight helps you. Now go and float some toolbars.


Calvin Sun is an attorney who writes about technology and legal issues for TechRepublic.


With all respect to Professor Platt, developers rarely decide the features that go into a product. I'm astounded that he would write this, as it appears he has done a significant amount of consulting at Microsoft. Microsoft has a special breed of workers called PMs (program managers). They typically gather requirements, write specs, and negotiate schedules. They do not write the code and the chain of command parallels that of the dev team. If we take it on faith that users use only 80% of any feature set, the critical question is which 80%? It differs from user to user. Casual users may never create a style in Word. Professional writers do all the time. Since casual users vastly outnumber the pros, should Microsoft had omitted styles? I think you see my point. doug


Using dual (or more) screens make floating toolbars very useful. You put your app on one screen and move all the toolbars to the other one. That way you get back the real estate in the document window which reduces scrolling and clutter. I know there are features many/most people don't use, but I don't agree mainstream software should cater only to the lowest common denominator. It should be useful at all levels of expertise and ability. There should be deeper and richer functionality for those who need it or find it useful. Another classic example is array formulae in Excel. Most users will never even discover they exist, but those that do find an extremely useful tool that can do things that can't be done any other way except by coding up a macro. Regards


I agree that advanced features should be included in software whenever possible. Just make it so the novice user cannot easily activate these features by accident as in the case of the floating toolbars. For example: include an "Activate Advanced Features" in the File menu for the power user.