Chapter 10: Modularity and Libraries


As a programmer, you’re well aware of the importance of breaking certain parts of your code into libraries. Further, you’re aware of how to do that. But what are the usability issues of libraries? Does usability even stretch into the domain of libraries? Sure it does! And in this chapter I talk about such issues. I do not, however, talk about how to create a library, since that’s a topic you can find in introductory programming books and online help documents.

Dividing Your Product into Libraries

Libraries are a touchy issue. Some developers prefer to break up their code into numerous dynamic libraries, while other developers prefer to keep the whole program in a single binary executable file. And as for those who combine everything into a single binary executable file, some people prefer to divide the code into multiple static libraries that get linked into the final executable.

I’m not about to tell you what’s right and wrong in this regard from a developer perspective (primarily because each approach has its pros and cons). However, I am going to tell you how the users perceive libraries and what effect they have. Therefore, I’m going to assume that your projects either:

  • Include dynamic libraries

  • Link to static libraries

Unless you’re creating a rather small application, rarely will you develop a product that has no libraries, whether shared or dynamic.

Note

In this chapter I use the term dynamic for the type of library that lives in a single file separate from the binary executable file. This dynamic library gets shipped with your product. Unix people know this type of library as a shared library. On Windows, the library gets a .dll extension. On Unix, the file gets a .so extension.

Static versus Dynamic?

Before I get into the details of the usability differences between static and dynamic libraries, I’m going to sum it up with these two important points:

  • Static libraries make for larger executables.

  • Dynamic libraries allow for smaller executables but more files.

These two points can be either good or bad for the user. A single but large executable:

  • Can be easier to uninstall or move to a different directory

  • Can be difficult to download, since even a compressed .zip file containing the library can be large

REAL WORLD SCENARIO: If I Only Knew Who Invented Coax Cable

start example

Quick: What engineering design do you despise more than anything else on the planet? For me, the one I can’t stand is coax cable—you know, that kind of cable that goes between your cable TV and the wall jack. Yes, you’ve seen it; it’s that cable that has a little screw-on end.

Here’s the main problem I have with coax cable: It takes two hands to screw it in! One hand to hold the cable, and one hand to screw the end on. Why does one hand have to hold the cable itself? Because so often the screw-on part is too tight (due, perhaps, to corrosion or something), and if I try to turn the screw-on part without holding the cable in place, the cable will spin, too. And the moment I let go to reposition my hand for another tightening, the tension causes the cable to unwind, undoing my previous tightening!

Then I have another problem with coax cable: Trying to unscrew it, I encounter the same difficulties of trying to screw it in, only it’s usually sticking even worse, and again I need to somehow reach two hands down behind that VCR (as if one hand could fit, much less two).

I’m only going to say this once, and I’m going to scream it at the top of my lungs: WHO ON EARTH INVENTED THIS THING!!!! It’s clearly the work of the devil, straight up from that place in the center of the earth with eternal fire and brimstone.

Look at USB cables. They just snap right in. Why does coax have to be the way it is? No reason. No reason at all other than to frustrate honest, hard-working citizens such as myself who never did anything wrong to the engineer personally responsible for this abomination. My glasses are starting to steam up just typing this. I can feel smoke coming out my ears. I better go take my blood pressure medicine.

One day, as it happens, I stumbled across something that was so incredible I would almost happily trade in every last slice of pizza for some guarantee that this invention would replace every coax cable on the planet. This was a special, new kind of coax cable with no screw-on cap. Instead, it had a plastic cap that doesn’t screw, and the cord just slides onto the jack! It was amazing! It was truly amazing! I would say I was so thrilled by this invention that I hung the thing on the wall over the mantel for all to see. But that would have been a travesty to let it go to waste. Instead, believe me you, I put it this wonder cable to use! This cable is on the back of my VCR, transporting tiny little happy electrons from one end to the other as they eagerly do their work carrying data and information for my eyes and ears to behold.

Why would somebody make something so difficult to use? Using coax cable without the happy aforementioned invention is akin to making the user hold down the left mouse button while typing a paragraph with both hands. Imagine that. I don’t have to imagine it; I have experienced coax cable.

Be a good programmer and don’t do to your users what the coax engineers have done to me. You want your users to live long and prosper and purchase more of your products so you, too, can prosper, right? Make only good inventions with your computer.

end example

Dynamic libraries, on the other hand:

  • Allow for easy code sharing between applications

  • Allow users to download just the executable if they already have the dynamic libraries

  • Can make for a cumbersome installation when your user’s computer has to manage possibly dozens of files

  • Can also make for a difficult time when your user’s computer needs to locate the dynamic libraries

The Trouble with Dynamic Libraries

I’ll be blunt: In general, the whole issue of managing dynamic libraries has, since the early 1990s, been, frankly, a disaster. So you wrote a really great static library that you use in your application. Do you really believe that other developers will use this library? And further, what kinds of usability issues are present if another developer uses your library, in addition to the legal and financial issues?

Think about this: You created a great library, and another developer is using it. That developer distributes a program. Do you allow the developer to ship your library with his application? And do you require the developer to pay you a flat rate for using your library, or is it free? Or, heaven forbid, are you charging royalties on each copy the developer sells?

RULE

I say heaven forbid, because, frankly, don’t do that. Don’t sell a library and then demand a cut of every copy the developers sell. The reason is developers hate this kind of arrangement, and the moment they cross paths with your competitor who doesn’t require royalties they will ditch your product and go with the competition faster than you can say, “Pay me, please!”

And, of course, you might run into legal issues. Let’s say your library has a bug in it whereby if the other developer uses a certain routine wrong (in other words, goes against your documentation and requirements), it ends up wiping out a user’s database. The user promptly files a lawsuit against the developer, who tracks down the problem as being within your library. The developer then blames you, even though he used the product incorrectly. And although you feel you’re in the right, anybody can sue anybody, and before you know it you’re being sued as well. Can you say long, drawn-out court battle? Nice try. Frankly, I’d rather stay clear of that.

Those are just two of the financial and legal issues that could come up. But what about usability issues? Some developers might expect that your library is so incredibly popular that it will already be installed on every user’s computer. (Face it: that’s only going to happen if your company’s initials are MS.) But worse, what if the users do have your library, but it’s a different version from the one the other developer is expecting? Imagine if a developer’s product manages to link to the different version, and all is fine until one day the program crashes, displaying a message that there was a problem deep down inside a file that you created. Soon the other developer will be getting tech support calls and then will be routing the calls to you.

Many things can go wrong when a third-party developer uses your libraries. Here are some of them:

  • The third-party product’s installer might overwrite another version of the library that’s required for another product.

  • The third-party product might locate the wrong library.

  • The third-party product might simply use the library incorrectly for whatever reason, resulting in bugs that you get blamed for.

  • The third-party developer might not know that your library, in turn, requires certain other libraries, and then when the developer does a mass distribution of software, half of the installations won’t work because that other product isn’t present.

Regarding this final point, such a situation should not occur if the third-party developer did her homework on the installation process. The developer should have tested the software on a clean machine. Further, the developer should have used the various binary dump tools to determine exactly which libraries are present and whether or not such libraries are typically already installed on an end user’s computer. Still, if the developer doesn’t do all this, you could get blamed for the resulting problems!

But even though the developers (including you) end up getting into battles with each other, the person who ultimately gets the brunt of the punishment is the forgotten end user. Here this user has just paid good money for a software package, and the user might need the package for a business purpose. Meanwhile, as you and the other developer are fighting over who is at fault, the end user is growing more and more frustrated by the day as the product does not function. Remember, software is for the end users. Yes, you may be in it for the money, but the software itself ends up on the end user’s computer, and that’s the person who must live with this potential garbage.

But even if a third party isn’t using your dynamic library, users can still run into problems. Here are some issues:

  • You happen to name your library the same as somebody else’s library. Two programs end up on a single computer, each requiring a different library that has the same name, and at least one program picks up the wrong one.

  • A user installs two programs, and both require the same library. (Both programs might have been written by you!) Later the user uninstalls one of the programs, and oops, the dynamic library got uninstalled as well. Now the remaining program no longer functions.

But things can get worse:

  • Your library uses certain resources (such as a log file or a hardware port) and two programs use your library. A single user runs both programs simultaneously, and one of the programs crashes.

  • And one final usability issue that I can think of (among many more, no doubt) is this: The user’s computer ends up with dynamic libraries thrown every which way, piled in every directory imaginable, making for a Royal Disaster of a Hard Drive.

For what it’s worth, Microsoft has even identified the realities of this Royal Disaster, and the marketing people at Microsoft have even informally adopted the term DLL Hell to describe the situation. (Microsoft has attempted to solve this problem with their .NET architecture, confining the dynamic libraries to the private bowels of the system directory known as the Global Assembly Cache. Dante would be proud.)

Frankly, life need not be this way. I would like to think that my software never runs into this problem. Why? Because back in the 1990s, I worked for a software company that did something right: They spent a lot of time carefully organizing their libraries. (They did this because they created libraries for use by third-party developers.) There I learned how to make dynamic libraries right. All these problems I’m describing in this section need not occur. Therefore, please don’t think I’m saying you shouldn’t use dynamic libraries. I’m not at all. Instead, in the remaining sections of this book I talk about the correct way to create and use dynamic libraries, in addition to shared libraries.




Designing Highly Useable Software
Designing Highly Useable Software
ISBN: 0782143016
EAN: 2147483647
Year: 2003
Pages: 114

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