So I'm sitting at my desk, mouse in hand, digging through the guts of my Mac, trying to track down yet another pathetic bug. The only trouble is, this is getting dull. I've done it a thousand times, and I always win; it's just a question of how much time the old ball and chain is going to eat up this time. Worse, the wind is blowing 20 knots right outside my window, and for the windsurfers in the crowd, you know the exquisite torture of good wind that you aren't allowed to transform into mind-blowing speed.
Maybe for you it's that you'd like to get home to see your insanely great mate. Or you've got kids whose names you can't pronounce. It's even likely that some of you just graduated from college and are still astonished that they pay you for something that's so much fun. But you're thinking, "If I can get this bug fixed quickly, I can get back to writing that rad Marathon hack to make the other net players slower than me." Perhaps your boss has started to notice that you spend a lot of time on the job but you don't really get very much done. Getting a little nervous? What if he's thinking of pulling the plug on your baby because you're too slow?
Or maybe you shipped the 1.0 version, but it had a few too many bugs, and MacWEEK was so incensed that they broke with the tradition of objective journalism and are calling for your head. People who bought your software with actual money have been calling every day, filling your answering machine with unveiled threats. It seems that you left a bug in there that just cost several thousand people each about two weeks of valuable time, reentering their data.
In particular, recognize that the wasted time from programming errors and bugs gets exponentially more expensive the further into the process you get. If I make a syntax error, I just fix it and recompile. If I toss buggy code over the fence to the testers, now I'm wasting their time. If I ship software with occasional crashing bugs that I just can't quite track down, I'm wasting thousands of people's time.
The point is, there are lots of ways to waste time while programming. I'm here today to offer some ideas on how to save time through better programming habits, so that you can take up windsurfing, or maybe the electric guitar, or learn how to pronounce your kids' names, or gain "the power to crush the other kids" while playing Marathon. Whenever I mention windsurfing, substitute your favorite quality-of-life enhancer.
I'll use some real life examples, and we'll see what sorts of lessons we can learn from them. I've categorized these ideas in three ways. First, there are some obvious time wasters that can be eradicated; these aren't really bug related, just daily time wasters. Considering how much time bugs cost, the second category consists of high-value rules that can find bugs quickly and painlessly. Finally, there are the super-value rules that prevent bugs from happening at all. Be sure to consider how these ideas might apply in your specific circumstances.
Even with small chunks of code, I've found it helps to review the pasted code line by line, carefully, and not to assume that since it ran before, it'll run now. Some subtle assumptions may have changed, and even though reusing code is certainly superior to writing it again, don't be misled into thinking this is risk free. A more powerful technique is to seriously modularize code, so that when I copy and paste I take an entire routine, not just a few lines. With a well-defined interface, the chances of blowing it are greatly reduced. This means adopting the habit of writing each routine with the idea that I'm going to reuse it later. This radically improves every routine I write.
New rule: Reuse code modules, not code fragments. If the code has to be altered, inspect it as if it were new (which it is).
Comments really are necessary to make code reusable and maintainable. I always write "strategy" comments, which say what the routine is trying to do, and avoid writing "tactical" comments, like what it's doing line by line. Remember, sometimes the time savings occur in the future, not at the moment. I've found that skipping comments is being penny wise and pound foolish. Usually the strategy comments help clarify my thinking on the routine as well, so there actually is a short-term gain.
New rule: Always write strategy comments. It's possible to decipher intent from the code, but why not just explicitly say it?
Well, guess what? These machines are so stuffed full of junk nowadays that saving just one or two lines is as meaningless an effort as trying to decide how many demons fit on the head of a transistor. Worse, I spent my own valuable time deciding something that has zero impact. Sorry, no can do anymore. My philosophy now is: write it straightforward, easy to read, vanilla. I want to save my windsurfing time, not pretend that I know up front what needs optimizing. In the Anaclock example, the computer had an entire second between screen updates. When I actually measured execution time, all the time was spent in CopyBits updating the screen, and waiting in the main event loop for the next second to arrive. There was zero measurable time in my entire clock calculation and offscreen drawing code.
New rule: No premature optimization. Measure with performance tools first. Then optimize only where it counts.
There are lots and lots of tools available now, and I use all of them. I don't care how hard they are to use; if they can find a bug in seconds that might take me hours or days, then I win. This includes such notorious tools as Blat and Jasik's debugger. I know Blat's a pain, since it doesn't work on all machines, but hey, it's too valuable to skip. Same with Jasik's debugger. Sure it's confusing, but it's got features no one else provides. Before throwing the software over to the testers, I make sure it passes all the tools.
High-value rule: Use the best tools, all the time. Don't spend time in a debugger when a test tool will hand you the answer on a silver platter.
Sometimes learning those new tough coding tools can really pay off. I generally try to sample every new tool and coding advance that comes along to see if it can help me save time. MacApp was clearly a massive win, because it focused my programming onto teensy parts to be added instead of all the Toolbox calls of a typical application. In addition, it was fully debugged and very robust, giving me a more solid final application. I try not to be wedded to any given style or approach; I just want to use the best stuff currently available.
High-value rule: Try new things. New ideas, approaches, tools, and programming styles can be like winning the free-time lottery.
After seeing similar bugs go by several times, it becomes clear that something must be done to stop that kind of bug. I don't want to spend time fixing the same problem over and over again, so now my goal is to permanently fix bugs so that they can't happen again. By this I mean changing how I do things, so that that specific bug will either be caught quickly or never happen again. It can be as simple as adding a test to a test suite to ensure that bugs of that form are caught immediately, or adding an assert to catch that error. Or it can be as hard as changing my programming habits to never use pointer math. Whatever it takes, I try to learn from each bug and make sure it can't happen again. Especially after I've done something twice, it's time to write a tool to fix that problem.
High-value rule: Learn from mistakes. If my dog gets bonked on the nose every time he gets near the door, he learns to avoid the door. I want to be at least as smart as my dog.
Since I started noticing how much time bugs cost, I've changed my mindset on them. I no longer automatically accept that code will just have bugs. I hate 'em. I want to kill 'em. Better, I want to kill 'em before they hatch. Since they take up my personal time, I feel it's only proper to take it personally when they show up.
Super-value rule: Write with quality in mind. As they say, the inner game of programming is so important.
What to do? Don't "improve" code, unless it's never been debugged. Any fully debugged code, no matter how shoddily written, is superior to newly written code, no matter how pristine. It went against my grain, but the right answer was to leave it gross. That heavily used Font/DA Mover code had thousands of hours of value in it, with literally millions of testers, that were all lost when I rewrote it. Rewriting it took time that I wanted to spend on something more valuable, like fixing the last few remaining bugs -- and then getting outside and windsurfing! Once I rewrote the code, it was like a new program, and thus needed a full development/testing/debugging cycle. I backed off to an earlier "skanky" version and just debugged that.
Super-value rule: Never rewrite something that's been fully tested. It may be ugly, but evolution is on its side.
OK, so it's clear that being "clever" often winds up being a way to play tricks on myself. Is there anything wrong with doing it simply, in a straightforward, vanilla style? I know for sure I'll get it done sooner and, even better, the programmer who has to maintain this code won't have to waste a bunch of time understanding mindless tricks (remembering of course that that maintenance programmer might very well be me, two years after I forgot what tricks I was playing). And let's just forget the malarkey about it saving code. Is it really worth saving 10 whole bytes out of a 16 meg machine, at the expense of wasting my time? I want to count cycles and bytes only in places where it makes a measurable difference.
Super-value rule: Write vanilla code. Doing it simply, and the same way each time, also makes it more likely to be correct.
The answer, although I didn't use the name at the time, was to use asserts. These have been talked about a fair amount, and you've probably used primitive asserts under the name of DebugStr. Nowadays, the most powerful combination I've used is to hook together asserts with a failure handler like MacApp's catch/fail mechanism. Asserts make it easy to build a debug-only version that checks every stupid thing that can go wrong and lets me know right up front during testing, but doesn't compile into the final version. The catch/fail stuff makes it easy to handle every possible error in a graceful way. (See the article "Using C++ Exceptions in C" in this issue.)
If something absolutely positively cannot fail, I use a debugging-version assert to catch the occasional times when it does fail, so that I can surprise myself early and not spend hours tracking down the "impossible" error. One great thing to check with asserts is input parameters, to catch those inevitable times when some routine passes in rubbish.
Super-value rule: Use asserts along with a failure handler. Catching bugs as they happen is vastly superior to backtracking 15 miles after the program crashes.
BO3B JOHNSON (bo3b@rahul.net) is completely whacked out about windsurfing, and takes summers off in order to windsurf every day. But since it's winter, he's doing consulting so that he can pay for his next windsurf board and windsurf trip to Aruba. Bo3b prefers to be addressed as "Bob," since the 3 is silent.*
Where's Dave? That other Johnson, who usually writes this column, is probably at the public library researching his obsession du jour, taking his dogs for very long walks, or reclining on the couch reading a book. Since he's cut back his working hours, we're having guest Neophytes write this column. We can't promise they'll all be Johnsons, however.*
Thanks to Jeff Barbose, Jim Friedlander, Brian Hamlin, Fred Huxham, Dave Johnson, Jim Reekes, and Patty Walters for their terribly helpful review comments.*
