Tech Talk

Share |
E-Mail ArticleE-Mail Article Printer-FriendlyPrinter-Friendly

Software Design

Columnist: Michael E. Duffy
January, 2015 Issue

Michael E. Duffy
All articles by columnist
Columnist's Blog

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
[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.]


In this Issue

The Ancient Practice of Biodynamic Farming

Seeking stronger relationships with the Earth and ways to express truly unique terroirs, winemakers and vineyard owners across Napa and Sonoma are embracing biodynamics —“organics on stero...

Budding Business

The legalization of the cannabis market is predicted to generate more than $20 billion in U.S. sales, but rules and regulations are still in a state of flux....

Rocking the Wine World

Sonoma Cast Stone in Petaluma has been making concrete fermentation tanks for eight years. Owner Steve Rosenblatt started his company 20 years ago to create concrete for custom walls, countertops an...

See all...