Find it on amazon at Wrench in the System: What's Sabotaging Your Business Software and How You Can Release the Power to Innovate.

Back in the 80s, when I was getting started in a career in computer programming, I was faced with a new situation where I worked. We had an old (well, new at the time) IBM PC, and a really sweet daisy-carriage printer, along with an accounting program that had a pretty awesome report generator with its own built-in programming language. I was tasked with configuring it all. I finally got everything going, except the reports were running too wide. My boss wanted them printed on 8 1/11 x 11 paper, but they would only fit on landscape 11x14. I told my boss he’d have to change the way he did things.

“Nonsense,” he said. “I can’t have big sheets like that. They won’t fit in my binders,” he said as he pointed to the binders lining the shelves around his desk. “Go back and fix it.”

My young mind was furious. Why couldn’t he just change the way he does things? We’re only talking about binders, right?

Wrong. I learned an important lesson that day that has stayed with me since.

Software must conform to the needs of the people. Not the other way around.

Of course, there must be some leeway. Software has certain common elements that we, the human users, must adjust to, like how to use drop-down menus; how to click buttons; and so on. But once we understand such patterns and are willing to adapt to them, the software should be built for our needs.

This has become a bit of a mission for me. We, as programmers, shouldn’t just yell “RTFM!” if the majority of our users don’t understand how to use our software. Sure, there will be the occasional user we can’t reach—you know, the one who probably really shouldn’t go anywhere near a computer, let alone a car, a lighter, heavy machinery, etc., but if most of the users are confused, then it becomes our problem.

As part of my mission, I even went on to write a book about usability called Designing Highly Usable Software.

To date, of the dozen or so books I’ve written, that has been the single worst seller.

People—especially programmers—want none of it.

But think of it. You are a programmer. If you’re one of the majority of the readers of DevSource, then you probably work for somebody else, and you may well work for a large company with lots of programmers. And let’s be honest: Do you absolutely love the software you’re building (or, more likely, maintaining, as that’s what most of us really do)? Do you really think that this project you’re working on is perfect with no bugs and is easy to use? Do you look at it in awe, having never had a day where you felt like the software was junk?

Probably not. Most programmers I know quietly complain about how bad the software is that they’re working on. And it’s true: Look at the software you’re not working on but are, instead, a daily user of. Without trying to diss my own coworkers, I look at our content management application and can certainly think of some areas that it needs improvements, areas that it actually causes me to slow down and not be able to do my job as quickly as possible. In general, software does have room for improvement.

And think about this as you look at the projects you work on: Do you feel like there’s a “too many cooks” syndrome where you work? I mean, really now, do you need three project managers, two of whom have no experience building software, managing a team of six programmers, four of whom came running to you when because they couldn’t figure out how to install the SDK, making you wonder why they’re even in this profession?

And even more: How many times have you thought to yourself what can be done to improve this system you’re building and maintaining and how much better you could make it if “they” would only let you?

With that in mind, I want to introduce you to a new book called Wrench in the System: What's Sabotaging Your Business Software and How You Can Release the Power to Innovate by Harold Hambrose (ISBN 0470413433).

This is a beautiful hardcover book printed on glossy pages with full-color photos, and the author says exactly what’s been on my mind for a long time. When I was into the first chapter, I grabbed a highlighter, thinking I’d copy a paragraph or two for this article, but I soon found I was highlighting the entire book.

The first chapter starts right out talking about how so much software has turned into lemons—yet, unlike other products, we can’t just send it back for a refund. The author points out, “If you pay more than $25 for almost any product that doesn’t work properly despite its written warranty, the Magnuson-Moss Act will back you in court … which enables buyers to obtain satisfaction for goods that fail to perform…” But this doesn’t apply to software, thanks to the licensing agreements. He adds: “The owner of a $15 million software product that turns out to be too difficult to use has much less chance of obtaining a refund or a replacement than the buyer of a defective DustBuster.” Put simply (and these are my words, not the author’s): If the software sucks, you’re screwed.

Much of the book is devoted to good design in software. But design here means not just the architecture we programmers usually think of when we hear “design” but also the outer cover, the GUI, the thing the user sees and interacts with when using your software. Does the software actually do what it’s supposed to do without forcing the users to jump through hoops, and without slowing them down?

We’ve heard it before, yet so many of us refuse to listen. Good design matters.

And the good news with this book is that while pointing out the problems in so much software, Hambrose offers good, solid solutions for how you can improve your software. You won’t find any actual code in this book; in fact, Hambrose’s formal education is in design and not programming. But that’s actually good. They say that if you want to know what you’re really like, don’t look in the mirror but instead ask other people. Other people see things about us that we don’t see. And the same is true with an industry. With this book, we have an intelligent outsider who has stepped into our industry to provide us with what he sees is a fundamental problem. Sometimes that’s what it takes to kick us into high gear. But he’s not just an outside complaining; rather, he’s spent many years now immersed in our industry and is now a part of it, and offers excellent solutions that we would be wise to follow.

Will we learn from this? Will our software finally become usable? I certainly hope so. We can all start by picking up a copy of Wrench in the System by Harold Hambrose.

Jeff Cogswell is a Senior Editor with DevSource.com and eWEEK.com. Follow him on Twitter at twitter.com/jeffcogswell.