Wednesday, February 26, 2003

Leadership Roundtable, Windows Annoyances

This article appears in slightly different form in the January/February 2003 issue of IEEE Micro © 2003 IEEE.

The books I look at this time both deal with annoying behavior. One explores stupid programmer tricks to find truths about technical leadership. The other looks at unfortunate design choices in the leading operating system and sees annoyances to be ameliorated rather than obstacles to be cursed at.

Roundtable on Technical Leadership edited by Gerald M. Weinberg, Marie Benesh, and James Bullock (Dorset House, NY, 2002, 176pp, ISBN 0-932633-52-8, www.dorsethouse.com, $21.45)

This book is the second in a series of digests of threads from a moderated discussion group called SHAPE (Software as a human activity, performed effectively). Gerald Weinberg moderates the SHAPE forum. He charges subscribers an annual fee, which compensates him for the time he spends keeping the signal to noise ratio high.

In the July/Aug 2001 Micro Review I reviewed the first book in this series, Roundtable on Project Management. In reading that book, I noticed that the participants take certain background information for granted. The same is true to a lesser extent in the new book. Shared parables, aphorisms, and classifications greatly increase the depth and efficiency of the dialog, but they make it harder for outsiders to follow. For example, if you haven't learned about the Meyers-Briggs personality types, you probably have no idea what INTP or ISTJ signify. If you haven't read about the Do You Mean? game, the brief summary in this book won't adequately convey its value. The book's bibliography consists of only 13 items (6 by Weinberg), so it shouldn't be too hard to come up to speed. Even so, I had to go to Google to find the meaning of cargo cult programming.

The editors set the tone of the book with a small quote (unattributed there, but sometimes attributed to Harlan Ellison):
The two most common elements in the universe are hydrogen and stupidity.
At the heart of the Y2K problem was the idea of saving storage space by keeping only the last two digits of the year in applications that store and retrieve dates. This was a clever idea when data storage space was scarce and expensive, and 2000 was many years in the future. By 1999, most people regarded it as a stupid programmer trick. Weinberg began a SHAPE discussion thread on stupid programmer tricks, asking people to identify their favorites, explain why the tricks are stupid, and provide ways to avoid them. That thread occupies most of the book.

I'm not on the SHAPE forum, so I am contributing one of my favorites here. Back in the 1960s, the Digital Equipment Corporation (DEC) gave away in large quantities on college campuses a book about programming their PDP-8 computer. The first programming example in the book used the Increment and Skip if Zero (ISZ) instruction to modify another instruction in the program, so that the other instruction served as both a pointer and a loop counter. Modern computer architectures have made that a worse idea than it was 35 years ago, but even then it was a stupid programmer trick.

Not wishing to be totally negative, Weinberg turned the stupid programmer tricks thread into one that includes truly clever tricks. Two other threads on technical experts and gurus -- their teaching methods, and their behavior under fire -- round out the book. Weinberg considers the result to be an ideal supplement to his well known work Becoming a Technical Leader (Dorset House, 1986).

The first thing that strikes me about the stupid programmer tricks thread is that we learn so slowly. For example, one contributor, Jim Batterson, complains about overloading identifiers, that is, making them carry information about the items that they identify. His example deals with assigning numerical identifiers to people in such a way that numerical order of the identifiers is the same as alphabetical order of the people's names. Reading about the machinations this led to, I couldn't help remembering line numbers in the BASIC language -- a problem that plagued programmers from 1965 until the early 1980s. BASIC line numbers identified the lines for editing (there was no visual editing in 1965). They also provided the targets of jumps and subroutine calls, and they determined the order of program execution. If lines had consecutive line numbers, you could not insert code between them without renumbering them to make room. This put them out of sync with the printed program listing and broke the jumps and subroutine calls.

Another thing that strikes me about this thread is that one person's stupid is another person's clever. For example, James Bullock has this to say about Charles Simonyi's Hungarian notation, a widely used and widely praised scheme for naming identifiers:
So in terms of stupid tricks . . . Hungarian notation is right up there . . .. I don't want to have the type dragging around in the symbol name. Type conversion needs to be explicit, hard, and hidden. The only reason to drag the type around is to make sure that two things have comformable types when they should. But don't you know that? Shouldn't you know? Shouldn't the compiler/linker/environment help you out with this? (Not if it's C with errors suppressed, it won't.)
If this is a stupid programmer trick, it's another old one. The FORTRAN language used the first letter of a variable name to specify its type as long ago as the 1950s.

The stupid tricks theme doesn't stop at coding tactics. It addresses the widespread problem of confusing design, documentation, and documents. The design of a project determines the project's future. Knowing the key ideas and alternatives that the designers considered is essential to building, extending, and maintaining the code. Documenting the design is essential, but most design documents fail to do this. In fact, a videotaped interview with the designers is likely to be a more valuable part of the design documentation than the typical functional specification. If you don't read anything else in the book, the 12 pages that carry the discussion of stupid design document tricks will still give you your money's worth.

The thread on tricks arising from social inadequacy provides the segue from programmer tricks to leadership. The Programmer's Drinking Song (source: the Internet) will cut too close for comfort for many project teams:
100 little bugs in the code,
100 bugs in the code,
Fix one bug, compile it again, 101 little bugs in the code.
101 little bugs in the code . . .
Repeat until BUGS = 0.
The threads on leadership distinguish between experts, who can do the expert activity, and gurus, who can teach the expert activity. A guru, according to this thread, remains humble and accessible, while exhibiting patience, gentleness, playfulness, enthusiasm for learning, and empathy. As I write this, I am listening to a 1989 recording of Gurumayi Chidvilasananda, successor to Baba Muktananda, leading a chant of the Guru Gita (Song of the Guru). I hope something rubs off. Experts have answers, gurus have questions. Do you think you'd like to read this book?


Windows XP Annoyances by David A. Karp (O'Reilly, 2003, Sebastopol CA, 586pp, ISBN 0-596-00416-8, www.oreilly.com, $29.95)

This is the most recent in a series of books that began with Windows Annoyances (O'Reilly, 1997), which deals with Windows 95. Subsequent books deal with Windows 98 and Windows ME.

The title of the book might lead you to believe that Karp is asking you to listen to him whine about the inadequacies of the Windows operating system. In fact, though, Karp takes a positive attitude toward the frustrating aspects of the Windows XP design. He doesn't waste much time whining about them. Instead, he shows you ways to work around them and to fashion an environment that you like. Along the way he even points out helpful features that you may not have noticed.

Karp wisely starts by showing you the basics. I've been using Windows heavily for more nearly 15 years, but Karp's Basic Explorer Coping Skills chapter taught me a few things I didn't know. And I was delighted to find that Windows XP provides a capability equivalent to the Show All feature of the late, lamented Xtree program. I remember when Xtree's incompatibilities with Windows 95 forced me to switch from Xtree to Windows Explorer. I am glad that Windows Explorer is finally catching up.

Karp teaches you how to work safely with the Windows registry, then proceeds methodically to explore all of the ways to customize Windows XP. The wonderful thing that Karp brings to this is his overviews of how the options control the underlying mechanism. Windows is maddening in this regard. It gives you lots of options but no way to understand what they do. Karp is co-author of Windows XP in a Nutshell (O'Reilly, 2002), so he understands all of the details.

I have paged through this book and seen dozens of changes I want to make to my system (probably not the Internet enabled fish tank, though). The book is comprehensive and detailed. I think it will keep me busy until the next version of Windows comes out. In fact, my only real complaint is that it could use a more thorough index.

Don't be fooled by the title. This is a very useful book. If you use Windows XP, you need it.