Reusing Code


Just as the Mexican builder put construction cost ahead of design considerations, engineers, left to their own devices, will value programming efficiencies more than user needs. The strongest evidence of this is the reuse of code that has been written for some previous project or that can be purchased for some nominal sum from outside vendors. Prewritten code not only saves time, but it has already been proven to be usable by other programmers and to be bug free in operation. One of software's unique properties is that any procedure can be invoked with a single command, but there is no limit to the magnitude of the invoked procedure. In other words, as long as the procedure is already written, all it takes is a single command to employ it. Therefore, any prewritten module of code is a significant boon to programmers. They can plug it into their program as a black box whose inner workings need never be plumbed. The programmer is spared not only lots of coding, but lots of thinking and testing, too. To most programmers, code reuse is more important than almost any other technical consideration. Famous open-source guru Eric Raymond says, "Good programmers know what to write. Great ones know what to reuse."

The primary side effect of code reuse is that large portions of most programs exist not because some interaction designer wanted them to exist, but because some other programmer already did the work on someone else's budget. Much of the software that we interact with exists for the sole reason that it existed before.

For example, our desktop software has so many menus and text-based dialog boxes because all windowing systems Microsoft Windows, Mac OS, OS/2, Linux provide prewritten code modules for these functions. Conversely, none of those systems provides much prewritten code for dragging and dropping, which is why you see so few direct-manipulation idioms in software interaction. A dialog box can be constructed in about 6 or 8 lines of easy, declarative code. A drag-and-drop idiom must be constructed with about 100 lines of very intricate procedural code. The choice for the programmer is obvious. The benefit for the end user is generally overlooked in this economy.

I see the Mexican-builder story played out in software development all of the time, mostly because of the programmer's compulsion to reuse code. Ed Forman, the head of development at Elemental Software, creates a detailed and accurate sketch of exactly what he wants the screen to look like before assigning it to his programmers. And yet, Ed says, the program that comes back to him is always just a pale shadow of what he drew.

It works like this: Ed's sketch shows dark-gray buttons on a light-gray background. The programmer will begin construction by copying the source code from some other already working part of the program. This is a good way to save programming time and effort, apparently benefiting everyone except that the existing code has an extra dark-gray border around the buttons. The dark-gray border also comes with a text legend. Instead of removing the text and the border to comply with Ed's sketch, the programmer will just leave it there, thus saving lots of code. The code requires some text for the legend, so he just puts something appropriate from his technical point of view there.

When Ed finally sees the program, complete with the unwanted border and confusing text legend, he shakes his head in amazement. When he points out the differences to the programmer, the programmer doesn't see a problem. Just like the Mexican builder, programmers believe that their own imperatives of construction simplicity and ease of acquisition of prewritten source code in their case take precedence over any suggestions made by others.

Ed is amused as well as frustrated by this, but he is at a loss to explain the phenomenon. His programmers are uniformly intelligent, capable, and deeply concerned about the quality of their products and the success of their company, but they simply cannot resist the siren's song. Sure, they will try to build Ed's vision, but not at the expense of their own implementation priorities.

graphics/kolam.gif

A fascinating aspect of the imperative to reuse code is the willingness with which programmers will adopt code with a questionable pedigree. Some inexperienced programmer will hack out the first interaction idea that pops into his head, but once it is written, that piece of code becomes the basis for all subsequent efforts because it is so aggressively reused.

In Windows, for example, the really experienced programmers built the internal processing of the operating system, but the first sample applications that showed third-party developers how to communicate with the user were written by a succession of summer interns and junior coders at Microsoft. The Windows internal code has been upgraded and rewritten over six major releases, and it has steadily improved. However, an embarrassingly large number of popular applications have in their hearts long passages of program code written by 21-year-old undergraduates spending a summer in Redmond. The same is true for the Web. Amateur experimenters hacked out the first Web sites, but those who followed cloned those first sites, and their sites were cloned in turn.

As you can see, there is a clear conflict of interest between what the user needs and what the programmer needs. We anticipate conflict of interest in countless activities and professions, and we have built-in safeguards to curb its influence. Judges and lawyers have skills in common, but we never let lawyers adjudicate their own cases. We never let basketball players referee their own basketball games. The conflicting interests are clearly visible, yet we consistently let programmers make design decisions based on personal implementation considerations.

It is a widely held view, in both the software-product industry and in corporate IT departments, that programmers are the people best equipped to design software because they are the local experts with the most thorough knowledge of the pertinent issues. Although it seems innocent and natural to let programmers determine the form and behavior of the software they will build, the trap of conflicting interests is unavoidable. The trap is insidious not because of the differences between the programmer and the user, but because of the similarities. The user wants to achieve his goals, and the programmer wants to achieve hers. The problem comes from the subtle differences between those goals.

graphics/kolam.gif

Programmers become so familiar with code reuse that they often copy existing techniques even when they aren't actually copying code. This comes naturally, coupled with programmers' tendency towards conservatism. For example, most programs have lots of confirmation screens, virtually all of which are unnecessary. Many of them exist because they existed in reused code, but many of them exist because programmers are simply habituated to putting them in.

For example, I ran into Jeff Bezos, the founder of Amazon.com, at a conference and told him how much I like the "1-Click" interface on his Web site. This interface allows you to purchase a product with big surprise one click. The interface is really well designed, because it pushes all of the annoying details out of the interface and lets the user merely click one button without reentering shipping and billing information.

Jeff was pleased to hear that I liked 1-Click, and he told me that when he and his designers had cooked up the idea, they presented it to the programmers, who duly nodded and agreed that they could do such a thing. The programmers went off and coded for a while, then brought the finished work to Jeff for him to try. He found a book he wanted and pressed the 1-Click button, whereupon the program asked him a confirming question! The programmers had converted his one-click interface into a two-click interface. To the programmers, this was simply an additional click what's the big deal? To Jeff and to every user it is a 100% inflation rate! Jeff had to wheedle and cajole before the programmers really made the 1-Click interface have only one click. Jeff won't tell me how much 1-Click has increased sales, but I can tell you that it has doubled my personal book-buying rate.

I have seen this behavior countless times, even from the most conscientious and capable programmers. They take our precisely rendered screen shots and treat them as vague suggestions for the interface. They take our list of functions and features and cherry-pick those items from it that they personally agree with or that are particularly easy for them to build.



Inmates Are Running the Asylum, The. Why High-Tech Products Drive Us Crazy and How to Restore the Sanity
The Inmates Are Running the Asylum Why High Tech Products Drive Us Crazy &How to Restore the Sanity - 2004 publication
ISBN: B0036HJY9M
EAN: N/A
Year: 2003
Pages: 170

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net