You are here: Articles --> 2001 --> The domino effect: unforeseen consequences

Vous êtes ici : Essais --> 2001 --> The domino effect: unforeseen consequences

The domino effect: unforeseen consequences

by Geoff Hart

Previously published as: Hart, G.J. 2001. The domino effect: unforseen consequences. http://www.techwr-l.com/techwhirl/magazine/usersadvocate/usersadvocate_dominoeffect.html

Complexity fascinates me. The more I learn about how computer hardware interacts with software, including the operating system, the more amazed I grow that it all hangs together as well as it does. And when it doesn’t, and things come crashing down around our ears, I find myself glad to be an educated layman looking in on things from the outside rather than the programmer or engineer who has to try to make things work right in the first place.

Technical communication seems pretty tame by comparison, since we generally get to work with small, simple, discrete things, and these make up the bulk of our work. As a result, we’ve all gotten pretty good at documenting these simple things: menu choices, dialog boxes, and basic overviews of software and how it works are all easy for us to describe. The problem is, we tend to document these things in isolation, and particularly so if we’re working in large teams on really large documentation projects. The problem? As soon as you start combining those simple elements, things can go badly astray. It’s kind of like setting up a row of dominoes in an attractive pattern, and just assuming that because each one stands so well on its own, the whole pattern will keep on standing.

Software and hardware are complex enough, but as soon as you let a bunch of unruly, creative humans play with them—such as when you network a bunch of computers—you’ve got a real recipe for disaster. In fact, networks provide a really good example of complexity and what we can do about it. Even when network geeks plan things scrupulously, and all their modifications to the network and server seem to go flawlessly, the odds are good that somewhere, one or more of our beloved users are going to trip over those changes and fall down hard. If those people happen to be in positions of power, or have friends who hold such positions, the network people are going to be hearing about those pratfalls for a long time to come. And much though we may curse the computer staff sometimes, that doesn’t mean we want to produce documentation that lets them fall on their faces, since other people just like us are going to bear the consequences.

It’s obvious that almost all the changes made to a network will affect the community of its users, but considerably less obvious how subtle the side effects of those changes can be. For example, one company I know set up corporate e-mail access to the Internet long after they’d already established user names for logging onto the network. Originally, one of the network architects recommended creating login names so short that nobody would complain about typing them in: each person would be represented by a three-letter acronym based on their initials, so for example, mine would have been “ght”. This was a great solution because the company was small enough that there were few conflicts among the names created using this system, and it was quick and easy to type internal addresses when you needed to send someone e-mail.

But when they added Internet e-mail, someone pointed out that longer, more memorable names would be more helpful for their clients. So they implemented that system, and the simple three-letter internal addresses suddenly became longer addresses, with the elegantly concise “ght” becoming (for example) “geoff-hart@example.com”. Unfortunately, nobody thought to ask the e-mail users whether this change would have any effect beyond the need to rewire their fingers to type the new, longer names. And sure enough, that one small change toppled a whole line of dominos. Users who’d been profitably using work-related e-mail discussion groups suddenly found themselves unable to receive mail from those groups. Why? The old e-mail addresses continued to receive mail, which was promptly discarded by the mail server because there was no longer anybody by that name in the company’s e-mail directory. Worse yet, the new longer names weren’t registered with the software that managed the discussion groups, so the owners of those names couldn’t rejoin the discussion until they figured out what had happened and resubscribed under their new names. Similar problems arose for business-related e-mail, and a fair bit of useful information probably got lost along the way.

To complicate matters, few people realized it would be important to unsubscribe from the old discussion groups when they resubscribed under their new names, so the mail server found itself receiving twice its usual volume of mail (once to the old address, and once to the new) until the problem was resolved—and resolving the problem was sometimes difficult, since the "unsubscribe" process sent a confirmation request to the old e-mail address. Even once everyone understood what was going on, there wasn’t a lot of urgency to fix the problem until someone high up the corporate food chain complained.

The problems eventually faded away, but not before the network manager’s reputation was tarnished. And what’s sad about this is that the problem could have been avoided simply by developing a group of knowledgeable users with whom to discuss the proposed changes and hopefully spot such problems—before they toppled a line of dominos that ended on a manager’s desk. Lesson 1 is that even when you know the software inside out, you rarely understand completely how people are using it. And that can hurt them, and maybe even you. Lesson 2 is more relevant to us as technical communicators: understanding that e-mail addresses may be used for far more than internal e-mail might have tipped off a clever writer to warn network administrators about all the possible consequences of changing a user name. Perhaps even to include a warning to this effect in the procedure that explains how to change user names.

How do you plan for these sorts of problems and document them so that nobody has to find out the hard way that they exist? You can’t, really; complex things are... well... complex, and their interactions even more so. A branch of mathematics-influenced software development called “formal methods” and the growing science of “complex systems” will eventually arm us with the tools we need to handle these problems. In the mean time, knowing that dominos sometimes fall over and interact with other dominos should at least remind us that we can’t safely document simple things on the assumption that they exist in isolation.

©2004–2024 Geoffrey Hart. All rights reserved.