Coding Horror

You may know Bruce Tognazzini from his days as Apple Computer employee #66, or perhaps his classic books Tog on Interface and Tog on Software Design. He's still quite relevant today; his list of the ten most persistent UI bugs is an excellent reminder that many of the biggest computer interface problems are still essentially unsolved.

But what I want to talk about today is one particular Ask Tog column from August 1989, which was republished as Chapter 6 of his book Tog on Interface. It's titled Keyboard vs. The Mouse, pt 1. It contains this quote:

We've done a cool $50 million of R & D on the Apple Human Interface. We discovered, among other things, two pertinent facts:

• Test subjects consistently report that keyboarding is faster than mousing.
• The stopwatch consistently proves mousing is faster than keyboarding.

This contradiction between user-experience and reality apparently forms the basis for many user/developers' belief that the keyboard is faster.

Let's assume that we're typing some text into a document of some kind, and we wish to save the document we're working on. (I could argue that the user should never have to explicitly save anything, but humor me.) If it seems ridiculous that the mouse method:

1. Take your right hand off the keyboard
2. Place your right hand on the mouse
3. Mouse over to the File menu
4. Click File
5. Click Save
6. Place your right hand back on the keyboard

Could be measurably faster than the keyboard method:

1. Use your left hand to press Ctrl + S

I assure you that you are not alone. Please defer all your righteous indignation for just a moment.

First, understand that this is a very old quote. In 1989, the current desktop operating systems were Windows 2.0, DOS 4.0, and Mac System 6. The "people new to the mouse" Tog refers to were keyboard holdouts, convinced that the mouse was nothing more than a giant, gimmicky waste of time. I don't think you'll find many users like that around today. Furthermore, I doubt Tog envisioned today's world of main menus with literally thousands of commands, a menu tree – no, a menu forest – so dense that search or some other alternate UI metaphor is the only rational way to navigate it all.

This ancient quote is invariably trotted out during any discussion of keyboard shortcuts, and always for the wrong reasons. The first paragraph is all most people read, so they misunderstand the full meaning. It helps to read the entire column. Tog explains keyboard shortcuts the way modern users understand them just a few short paragraphs later:

And, in fact, I find myself on the opposite side in at least one instance, namely editing. By using Cmd+X, C, and V, the user can select with one hand and act with the other. Two-handed input. Two-handed input can result in solid productivity gains (Buxton 1986).

I don't think anyone would argue that learning keyboard shortcuts is faster than using the mouse to navigate and learn a program. Clearly it isn't – it's quite painful, as anyone who has ever been stranded at a Unix command prompt can probably tell you.

However, as Tog himself notes, when the keyboard shortcut is already memorized and well understood, it's a clear productivity win.

I've long been an advocate of two-fisted computing – using both your keyboard and your mouse to the fullest. That's what keyboard shortcuts are to me. I'm not sure why this always has to be spun as a cage match between the keyboard and the mouse. Keyboard shortcuts don't replace my mousing; they complement it.

In my experience, there's absolutely no question that judicious use of a few keyboard shortcuts will make you faster and more productive. But you don't have to take it from me. Just Ask Tog.

I lived in the Denver area at the time Denver International Airport's completely computer automated baggage system was unveiled in 1994. The troubled development of this system was big local news.

The premise of Denver's plan was as big as the West. The distance from a centralized baggage check-in to the farthest gate - about a mile - dictated expansive new thinking, planners said, and technology would make the new airport a marvel. Travelers who arrived for check-in or stepped off a plane would have their bags whisked across the airport with minimal human intervention. The result would be fewer flight delays, less waiting at luggage carousels and big savings in airline labor costs.

Tours that preceded the system's debut led invariably to an airport basement where 26 miles of track, loaded with thousands of small gray carts, sped bags up and down inclines as conveyor belts minutely timed by the computer deposited each bag in its cart at just the right moment.

The baggage system was an abject failure. It had huge problems on opening day, and almost immediately had to be superseded by manual procedures. Things never improved much from there. Denver's automated baggage handling system was scrapped completely by 2005, in favor of traditional manual handling and barcode scanning procedures.

"It wasn't the technology per se, it was a misplaced faith in it," said Richard de Neufville, a professor of civil and environmental engineering and engineering systems at the Massachusetts Institute of Technology. Professor de Neufville said the builders had imagined that their creation would work well even at the busiest boundaries of its capacity. That left no room for the errors and inefficiencies that are inevitable in a complex enterprise.

"The main culprit was hubris," he said.

I was surprised, then, to read essentially the same scenario play out 10 years later in England at Heathrow Airport's new Terminal 5.

Many things did not go according to plan at T5, but at the core of the fiasco is baggage. This is supposed to be a state-of-the-art system, the biggest in Europe with 10 miles of conveyor belts controlled by 140 computers and designed to process 12,000 bags per hour at up to 23 mph. But it had never been tested before in a live terminal. On T5's D-Day many aspects -- human and technological -- simply did not work.

BA say they are confident that a few days bedding-down will sort out the problems. However, T5 is not yet at full capacity, with another 70 long-haul destinations due to move there on 30 April.

I sincerely hope BA can escape from Gilligan's Island, unlike so many hardy travellers before them. Otherwise, all we'll end up with is another sad entry in the long, dismal history of software project failure.

Despite Apple's historical insistence that the computer mouse should only have one button-- which led to the highly unfortunate convention of double-clicking-- most mice have more than one button today. In his classic book The Humane Interface, Jef Raskin revisits the earliest days of his involvement with the Mac project and realizes that the single button mouse was a mistake. Mice were meant to have multiple buttons.

What I did not see at the time is that multiple buttons on a mouse can work well if the buttons are labeled. If the Macintosh mouse had had multiple buttons, if the buttons had been permanently labeled, and if they had only been used for their intended function, a multiple mouse button might have been a better choice. A better mouse might have two buttons, marked Select and Activate, on top and on the side, a button activated by a squeezing action of the thumb. This last button would be marked Grab. Some mice at present have a scroll wheel on top that is used primarily for scrolling. Better still would be a small trackball in that location. The mouse would control the position of the cursor; the trackball could be used, for example, to manipulate objects or to make selections from menus that float with the cursor.

Doug Engelbart, the inventor of the mouse, also thinks that mice should have multiple buttons:

[Doug Engelbart] believes a mouse should have many buttons ... the only reason his original mouse design didn't have more than three was because they didn't have the technology at the time to make that possible.

Apple didn't ship a multiple button mouse until the Mighty Mouse was released in August 2005. It has four effective buttons, and even sports the trackball that Jef Raskin imagined in his book five years earlier. However, I've read a lot of complaints about the Mighty Mouse, most of which stem from the substitution of actual buttons with touch-sensitive surfaces.

I've used two-button mice as far back as I can remember on the PC. The meaning of the first two mouse buttons are very well defined in every graphical user interface by now:

But modern mice actually have at least three buttons. Where's the third button? Right under your mouse wheel.

Mouse wheels have been commonly available since 1996. In all those years, all those millions of mice shipped, no standard convention has emerged for what it means to press the middle mouse button.

Over the last two or three years, middle click has become strongly associated with tabbed user interfaces, at least in popular web browsers. Middle-clicking over a link opens it in a new tab; middle-clicking the tab itself closes that tab. This is happening in enough applications now that I think it's fair to call opening and closing tabs with the middle button an emerging convention. Still, it's a fairly loose convention, and the behavior is only defined for links and tabs respectively, and only in certain applications. What happens the rest of the time when you middle-click?

Another odd middle-click behavior that's defined in both Internet Explorer and Firefox is the modal "autoscroll mode". Middle click once on the page to activate this mode. Notice that the cursor changes. You can now use the mouse to determine the rate of scrolling. Middle-clicking again releases this mode and reverts to the normal mouse cursor.

I personally hate this behavior. I prefer to scroll explicitly with the wheel, and I often trigger this unwanted "mode" when I've slightly missed middle-clicking on a link. It can be turned off in the advanced options of Firefox but I can find no way to turn it off in Internet Explorer.

In the UNIX and X Windows world, the middle button has also meant paste since way, way back in the 1980s. I can't find any evidence of this behavior on Windows or the Mac, however. Pasting into text areas wouldn't necessarily conflict with the tab behavior, but it's an odd hodgepodge of behaviors to attach to a single button.

I hope over the next few years Microsoft and Apple can decide on a set of standard middle mouse button behaviors. It's frustrating to me that millions and millions of mice have shipped with this button, and yet it's a total crapshoot what will happen when you press the middle mouse button in any given application under any operating system. If the first and second mouse buttons have standard, well-defined meanings today-- why can't the third button, too?

These are available as bumper stickers and t-shirts:

Here's my rhetorical question to you: why is this funny?

• The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!)
• There Ain't No Such Thing as Plain Text
• On the Goodness of Unicode
• Wikipedia article on Unicode

Here's hoping the next programmer who sees this is laughing, too-- and for the right reasons.

I like to re-read my favorite books every few years, so I brought Robert Glass' seminal Facts and Fallacies of Software Engineering with me on my most recent trip. I thought it was a decent, but imperfect read when I originally bought it in 2004. As I scanned through the introduction and table of contents, I realized that I've written about almost everything in this book by now.

I'm not sure I gave Facts and Fallacies its due on my first read.

Simply reciting the various facts and fallacies feels like a zen koan to software engineering. Even without any of the background discussion and explanation in the book, it's therapeutic to ponder the brief one sentence summaries presented in the table of contents. As you read these, what comes to mind, based on your experience?

People

1. The most important factor in software work is the quality of the programmers.
2. The best programmers are up to 28 times better than the worst programmers.
3. Adding people to a late project makes it later.
4. The working environment has a profound impact on productivity and quality.

Tools and Techniques

5. Hype (about tools and technology) is a plague on the house of software.
6. New tools and techniques cause an initial loss of productivity / quality.
7. Software developers talk a lot about tools, but seldom use them.

Estimation

8. One of the two most common causes of runaway projects is poor estimation.
9. Software estimation usually occurs at the wrong time.
10. Software estimation is usually done by the wrong people.
11. Software estimates are rarely corrected as the project proceeds.
12. It is not surprising that software estimates are bad. But we live and die by them anyway!
13. There is a disconnect between software management and their programmers.
14. The answer to a feasability study is almost always "yes".

Reuse

15. Reuse-in-the-small is a solved problem.
16. Reuse-in-the-large remains a mostly unsolved problem.
17. Reuse-in-the-large works best in families of related systems.
18. Reuseable components are three times as hard to build and should be tried out in three different settings.
19. Modification of reused code is particularly error-prone.
20. Design pattern reuse is one solution to the problems of code reuse.

Requirements

23. One of the two most common causes of runaway projects is unstable requirements.
24. Requirements errors are the most expensive to fix during production.
25. Missing requirements are the hardest requirements errors to correct.

Design

26. Explicit requirements 'explode' as implicit requirements for a solution evolve.
27. There is seldom one best design solution to a software problem.
28. Design is a complex, iterative process. Initial design solutions are usually wrong and certainly not optimal.

Coding

29. Designer 'primitives' rarely match programmer 'primitives'.
30. COBOL is a very bad language, but all the others are so much worse.

Error removal

31. Error removal is the most time-consuming phase of the lifecycle.

Testing

32. Software is usually tested at best to the 55 to 60 percent coverage level.
33. 100 percent test coverage is still far from enough.
34. Test tools are essential, but rarely used.
35. Test automation rarely is. Most testing activities cannot be automated.
36. Programmer-created, built-in debug code is an important supplement to testing tools.

Reviews and Inspections

37. Rigorous inspections can remove up to 90 percent of errors before the first test case is run.
38. Rigorous inspections should not replace testing.
39. Post-delivery reviews, postmortems, and retrospectives are important and seldom performed.
40. Reviews are both technical and sociological, and both factors must be accommodated.

Maintenance

41. Maintenance typically consumes 40 to 80 percent of software costs. It is probably the most important software lifecycle phase.
42. Enhancements represent roughly 60 percent of maintenance costs.
43. Maintenance is a solution-- not a problem.
44. Understanding the existing product is the most difficult maintenance task.
45. Better methods lead to more maintenance, not less.

Quality

46. Quality is a collection of attributes.
47. Quality is not user satisfaction, meeting requirements, achieving cost and schedule, or reliability.

Reliability

48. There are errors that most programmers tend to make.
49. Errors tend to cluster.
50. There is no single best approach to software error removal.
51. Residual errors will always persist. The goal should be to minimize or eliminate severe errors.

Efficiency

52. Efficiency stems more from good design than good coding.
53. High-order language code can be about 90 percent as efficient as comparable assembler code.
54. There are tradeoffs between optimizing for time and optimizing for space.

Research

55. Many researchers advocate rather than investigate.

I had forgotten how much ground the book covers; it's a perfect springboard to all the essential topics in software engineering.

I've posted on almost every one of these facts in the intervening four years since I originally read them. As I delved into the table of contents presented above, I could barely contain myself. I remembered and mentally checked each post off the list as I went: check, check, check. I've been accused of gratuitous self-linking in the past, so I won't clutter up the rules with dozens of links to my old posts on these topics. If you're interested, you can find it. That's sort of the point.

If those are the fifty-five facts, then these are the ten fallacies presented at the end. Fallacies have the ring of truth, but upon closer inspection, turn out to be problematic when applied to a real live software project.

1. You can't manage what you can't measure.
2. You can manage quality into a software product.
3. Programming can and should be egoless.
4. Tools and techniques: one size fits all.
5. Software needs more methodologies.
6. To estimate cost and schedule, first estimate lines of code.
7. Random test input is a good way to optimize testing.
8. "Given enough eyeballs, all bugs are shallow".
9. The way to preduct future maintenance costs and to make product replacement decisions is to look at past cost data.
10. You teach people how to program by showing them how to write programs.

If you're curious about the rationale behind these facts and fallacies, that's entirely the reason the book exists: to remind us to question what we're doing. We should be thinking about our craft every day, in some small way, on our own software projects. That's how we collectively advance software engineering-- by building our shared memory and history in the field. As Mr. Glass states in the introduction:

In presenting these facts, I am also indentifying problems in the field. It is not my intention to present solutions to these problems. This is a what-is book, not a how-to book. That's important to me. I want to bring these facts into the open, where they can be freely discussed, and we can act on them to make progress.

I encourage you to pick up a copy of the full book for a deeper exploration. I do believe there's a rich learning experience-- or a rich remembering experience-- here for those of you who choose to read on.