One extra mouse click may not sound like much, but multiplied by hundreds or thousands of uses by thousands or millions of users, it adds up.
I devoted most of my last column to debugging tools and techniques (in other words, “wolf hunting”), since no significant piece of software is created without exhibiting those “unexpected behaviors” known as bugs. But even bug-free software that does what it's supposed to do without errors can still be a pain in the ass to use. Why? That’s the challenge of software design.
I confess I have no formal software design training. When I was an engineering undergraduate, there was no course on it (the closest thing was a system design course, which I took). My first real exposure to software design was being one of the programmers who created the Chessmaster program back in 1986. I was responsible for programming the IBM PC version of the program. My boss, Les Crane (former-talk-show-host turned software entrepreneur), told me he wanted users to feel as though they were sitting in front of an actual chessboard, picking up the pieces and moving them about. So we did things that seem very simple now, like a cursor hand that would open and close around the pieces when picking them up, and visually placing a piece in front or behind other pieces as the user moved it about the screen. But the point was to make the software feel “natural” to the end user. It’s a memory that I recall whenever I start a new software design.
Broadly speaking, software design is the process of describing—in fine detail—what a piece of software is supposed to do and how it’s supposed to do it. The output of the design process is one or more documents containing that description. Software design documents are frequently compared to the blueprint for a house: An architect creates a set of plans that describe a house, and a contractor uses those plans to construct the house. This would be a better analogy if software had the equivalent of “building codes,” agreed-upon and legally enforced ways of doing things (along with other useful items like professional licensing for architects and contractor’s licenses for builders). Sadly, any damn fool can design a piece of software, and there are probably as many approaches to software design as there are people who design software.
Simply put: If your software has bugs, blame the programmers (and the quality assurance team). But if your software is hard to use, blame the designer.
Software design is a relatively new idea. As my November 2014 column pointed out, the first real computers came about in the mid-to-late 1940s as part of the war effort and spread to large corporations (the only nongovernment entities that could afford them). People adapted design techniques used in other large, complex and expensive projects (like building bridges or other large engineering efforts) to the process of building software.
Consider the user requirements for a bridge: It goes from one side of an obstacle to another, doesn’t fall down, isn’t jammed under normal usage conditions, doesn’t look hideous, keeps things from falling over the edge and so on. Most people, even engineers, can correctly identify them. But what about the user requirements for personal finance software? The first attempts at a product like Quicken basically required people to learn double-entry accounting. They’d correctly maintain your bank balance, but were a pain to use. Intuit (the maker of Quicken) had two revolutionary ideas. The first was to center its product around the user’s check register, not the double-entry ledger of the corporate accounting world. The second was to send employees home with customers to actually see how they used the software and incorporate what they learned into new releases of the product. Although hard-to-use software is still being built, this idea of “user-centered” design is now much more common in the software industry.
Very little software is used only once (even the space shuttle software was used on multiple aircraft on multiple missions). Good software design recognizes that the effects of a mediocre design choice will be multiplied. One extra mouse click may not sound like much, but multiplied by hundreds or thousands of uses by thousands or millions of users, it adds up.
We’ve progressed from designing software like bridges, because unlike the bridge, it’s relatively easy to modify software, even after it’s been “finished.” What’s ironic is that sometimes the biggest obstacle to releasing improved software is the users themselves. Once users have learned how to use something, even a badly designed something, it’s costly to reeducate them. Companies are loathe to bear that cost, whether it comes in the form of lost productivity or formal training time.
Sadly, most people have little say in the design of the software they use (and grumble at) every day. Even when a new version is released to address a bad design choice, users are rarely aware of the change, unless and until they upgrade. It’s depressing.
What would make the software you use better? Let me know at firstname.lastname@example.org.
[Endnote: My first Tech Talk column appeared in the January 2001 edition of Sonoma Business, so this column begins my 15th year of writing for NorthBay biz. Thanks to all my readers for your continued interest in my thoughts.]
Measles, mumps, chicken pox and other childhood diseases of yesteryear are making headlines again in the United States. Formally prevalent viruses and bacterium affected thousands of lives before a sc...
Located at 1410 Neotomas Ave. in Santa Rosa,NorthBay biz magazine is a monthly business-to-business publication covering Napa, Sonoma and Marin counties. This year, the magazine is celebrating 43 years of continuous operation. It originally hit the stands in 1975, when it was called Sonoma Business, and only covered Sonoma County. Norm and Joni Rosinski and John Dennis, acquired it in 2000 and changed its name to cover an expanded market. Today, the magazine is part of Amaturo Sonoma Media Group. More here..