All Kinds of Mistakes Your Coworkers Make

Nobody likes to be told they’re not perfect. So instead of telling you what mistakes you’re making (because I can’t know for sure), instead let me tell you about some of the mistakes your coworkers are making (like trying to burn up the poor processor). In the following sections, I talk about some problems your coworkers might have that can have a direct impact on the users.

Tight Loops and Burning Up the User’s Processor

I’ve occasionally heard programmers make fun of the coworker who occasionally includes a line like this in his code:

 sleep(1); 

The typical response (while laughing) is, “What, sleeping for 1 millisecond is going to have an effect on the program?” Well, in fact, yes. By carefully placing this line in your code, you can greatly reduce the chances of setting your user’s computer on fire (or, more likely, of causing the computer to melt). Pentium chips run hot. Have you ever opened up your computer and actually looked at the Pentium? You can’t really see it because it’s buried in the biggest heat sink this side of Jupiter, which is usually, in turn, underneath a fan blowing right down onto the heat sink. And the computer’s case will have at least a couple of fans, too. We’re talking hot.

The human heart is an amazing device, and sometimes people wonder, if the heart is just a muscle, how come it doesn’t get tired? Doctors (or, more likely, trivia buffs) like to point out that the heart does, in fact, rest a lot. The heart muscle is a special kind of muscle tissue that relaxes in between each beat. The amount of relaxing time is greater than the amount of beating time. If the heart didn’t get a chance to rest, we would probably live our lives like the hummingbirds, racing along at a hundred miles per hour and dropping dead after only a short time. (Hummingbirds live about three years.) Thank goodness for the resting time in between beats!

Today’s microprocessors, like the human heart, need a rest. If you have a laptop computer, you’ve probably been surprised and even a bit alarmed to hear the auxiliary fans come on occasionally. What caused that? This program might do it:

 #include <iostream>  #include <stdlib.h>  using namespace std;  int main() {      long long sum = 0;      for (long long i=0; i<100000000; i++) {          sum += i;      }      cout << sum << endl;  } 

Now actually, this program probably won’t make the fan come on, because it ends too quickly to really make the processor heat up. But if you were to put the inner loop inside an outer loop and perform this complex calculation, say, 50 times, then you probably will hear the fans come on. (Please don’t try it.)

If you’re on a Windows computer, try this: Type in the preceding program (without the extra 50-times loop), and start up Windows Task Manager. Click the Performance tab. You might also consider making the Task Manager “Always on Top” by choosing Options Always On Top.

Then compile and run your little test program. Watch the CPU Usage! There’s a screen capture in Figure 8.1 if you don’t care to try it yourself. The Usage is at 100%. You’ll also notice that the processor jumped to 100%, dropped a bit, and then jumped back to 100%. The first jump wasn’t caused by my program; rather, it was caused by the gcc compiler! I once nearly burned up a notebook computer trying to do an hour-long build with gcc. Bad program, bad! Fortunately, pressing Ctrl+S paused the compiler, and I was able to let the computer rest periodically.

Figure 8.1: The program runs the processor to 100%. That’s bad.

What’s causing this? Your program is running in a tight loop, without yielding to the operating system. Yes, you have a multithreaded operating system, and so the other threads do run. But you’re not giving the processor a rest. And if you’re writing scientific software, for example, that goes through lots of calculations, you run the risk of overheating somebody’s poor laptop (like mine).

The solution is to throw in a sleep statement, which allows the thread to rest a bit while the operating system tends to the other threads. But you don’t need to sleep with every iteration; that would slow your program down too much. Try some different numbers. For this sample program, I found that a sleep every 10,000 iterations worked well. Here’s the fixed code:

 #include <iostream>  #include <stdlib.h>  using namespace std;  int main() {      long long sum = 0;      for (long long i=0; i<100000000; i++) {          sum += i;          if (i % 10000 == 0) {              _sleep(1);          }      }      cout << sum << endl;  } 

Note

The implementation of the gcc compiler’s libraries that I used has _sleep instead of sleep; you can check the header files to see what your compiler has.

With this quick change, the Task Manager no longer shows the processor running at 100%.

But there’s a problem: Now the program runs considerably longer. Bummer. And so you have a trade-off. If you’re writing software that is extremely calculation intensive, you might consider a user option that allows for the presence of the sleep function. Some people have computers with really good cooling devices that won’t have a problem.

Invisible Programs Running in the Background

Programs that run in the background can be a problem to users. On a Windows system, for example, users can open up the Task Manager and look at what programs are running. Unfortunately, the Applications tab of the Task Manager shows only the programs that have a window. Any programs running in the background without a window show up only in the Processes tab. Unix users tend to be a bit more savvy and are more likely to use the ps command to see what processes are running, rather than just look at what windows are open.

Regardless of the operating system, a program running in the background can be troublesome, for many reasons:

• Users might not know the program is running.

• If users know the program is running, they might not know how to end the program.

• Users might know a program is running because they see its process name but not know what the program is or what it’s doing. This is especially a problem today with the huge number of viruses out there.

Be careful before shipping software that runs in the background. If I find that a program is running in the background and it has an obscure filename or process name, I worry that it’s a virus. This usually causes me to go to http://groups.google.com (formerly Dejanews) and start searching for information on the process name.

Tip

On Windows, I use an advanced program called Process Explorer, which shows information about each executable running, including the full path to the executable file. You can find this free software at the SysInternals site at http://www.sysinternals.com. Also, note that I say free, but licensing rules are applicable, including commercial licenses.

If your software must run in the background, here are some ways to make sure the users stay happy:

• Make it clear during the installation that the software will be running in the background.

• Include good documentation that explains how to use the software.

• Provide the users with a way to open a window to configure the software, even if this window is nothing more than a way to stop the program.

• Always include a way to stop the program.

• If you’re writing a program for Windows, seriously consider including a tray icon on the taskbar.

One really great example of this is the open source Apache HTTP server. On Windows, the Apache server follows all these rules. Here’s an example of the tray icon I presently see on my Windows computer:

The Apache server is represented by the icon on the bottom left. Above that is the icon for Zone Alarm, a firewall software package that also follows all these rules.

Unfortunately, way too many software packages don’t follow these rules. I won’t name names, but if you create and distribute such software, please consider the rules here. If nothing more, do you really want people to be afraid that your software is a virus?

Programs that Run upon Startup

Programs that start automatically when you start your computer are as troublesome as programs that run silently in the background. (In fact, often programs that run in the background also start automatically.)

I Love That Car Alarm That Goes Off Every Night

Ahh, car alarms. You’ve got to love them. They go off all the time. I recently did my civic duty and called the police because a car alarm was going off for about six hours early one Sunday morning. I even drove by the owner’s apartment, and there was the car, its headlights blinking for the world to see. Other neighbors were standing around looking at the car, complaining about it. (And I lived a good quarter mile away and it was terribly loud!) And so the police took care of it: They towed the car. I didn’t know that’s what would happen, and I’m glad the owner didn’t know I was the one who caused this. But then again, his little device caused me a great bit of frustration, too, so maybe fair was fair.

How many times have you heard a car alarm and immediately thought, “Somebody’s car alarm is acting up again.” Shouldn’t you instead be thinking, “Oh, no! Somebody is breaking into a car! Call the police! Call the FBI! Send in the Mod Squad!” But no, we don’t react that way. We have a modern technological version of the little boy who cried, “Wolf!”

Have you used a software program that was so unreliable that you got so you would expect it to crash—yet you had no choice but to use it because your boss required it of you? I can think of one in particular, but I’d rather not say what it is for fear of being sued. And the problem with this kind of software is that the disdain for it gets so bad that the disdain turns into pure, raw, unadulterated hatred. And from there, the people actually start laughing and joking about the software. “Yeah, I hate ________ software, too!” (Fill in the blank.)

Now imagine if you were on the team that developed that software. Sure, your bosses are getting rich. But what about you? Would you really want that on your resume come time to find a new job? I would think not. Therefore, make your software dependable. Make your software good, even if you’re not in charge of the project. Good software really is possible. (And maybe if all else fails, leave a copy of this book on your boss’s desk opened to this page. That might do the trick.)

The problem is often that during installation programs set themselves up to launch automatically at system startup without the user’s permission. That leads to the first rule for this section:

RULE

Always have your program ask permission before setting itself up to launch automatically at startup.

A surprisingly high number of software packages are guilty of this. Yes, it’s fine to have your software start at startup, but please ask for permission first. But that leads to a second tip:

RULE

Give the users a way to disable the automatic startup of your program.

Often users might like the feature at first but grow tired of it. And believe me, if you don’t give me a way to disable the automatic startup, most likely I will uninstall your software and throw it into the trash. Or, if you don’t include an uninstall option, I will delete it. (And I’m good. I will spend a half hour searching through the system Registry, wiping out all traces of your software!)

Tip

Time for a user tip: If you’re a Windows XP user and you want to see what software launches automatically on your system, you can run the msconfig.exe program, found in C:\WINDOWS\PCHealth\HelpCtr\Binaries. In addition, you can download a great free program called Startup Control Panel (which is especially good for pre-XP systems). You can find this program at http://www.mlin.net.

Writing Overly Complex Code

You might be surprised to find this heading in a usability book. After all, what does code complexity have to do with usability? Everything. The reason is that if the code is terribly complex, chances are great that the person on your team suffering from a complexity complex didn’t necessarily know what he was doing, and bugs can easily creep in. I’m very serious here. My experience is that true programming experts are few and far between, especially when dealing with a language such as C++, which allows code such as this:

 template<typename _Item, typename _Traits, typename _Alloc>      my_class<_Item, _Traits, _Alloc>      operator*(const my_class<_Item, _Traits, _Alloc>& __a1,      const my_class<_Item, _Traits, _Alloc>& __b1)  {      my_class<_Item, _Traits, _Alloc> __ptr(__a1);      __ptr.append(__b1);      return __ptr;  } 

Yes, if you look this over you can figure out what it does. But do you really trust your coworkers to write code like this? And what’s going to happen after they quit and you’re stuck maintaining this code? (Unfortunately, the various implementations of the C++ Standard Library are usually filled with code like this.)

Here’s a quick tip: If you’re using C++, you can easily typedef your sophisticated templates, and that alone will make your code easier to read and maintain and, most important, debug.

SUGGESTION

Have code reviews, and if you see overly complex code, encourage the author to rewrite it in simpler terms. In C++ this means breaking up complex lines into multiple lines and using plenty of typedefs.