In the headlights - Embedded.com

In the headlights

When deadlines loom large, keep your cool. Skipping steps is the fast road to failure.

When I was a freshman in college, my car was a nicely preserved 1935 Chevy Sedan. It ran great, but those old “Stove-bolt” sixes were famous for being cold natured. Forget Electronic Fuel Injection. With no automatic choke, no thermostat, not even carburetor heat, they didn't like to run cold. They needed a lot of choke and throttle magic to keep them running until they were thoroughly warmed up, and on a cold morning, that could take awhile.

Nowadays, cars have little personality. You get in, you turn the key, it starts, you go. If you've ever owned a pre-1960s car, you know that it wasn't always thus. Each car had its own personality, its own starting drill. For the Chevy, it was something like “choke out, pat the gas twice, throttle off, crank briefly, choke in ΒΌ inch, throttle down, crank again.” Each step takes a precise amount of time. The rule was simple: Follow the starting drill, the thing starts. Don't follow it, it doesn't.

I lived in a boarding house about a mile from the campus. With my lowly “C” parking sticker, it was hard to get a spot much closer, so I usually hoofed it. One cold, clear, sub-freezing morning, though, I decided to try taking the car. My friend Norman asked to come along. Being late as usual, and typical college freshmen, we didn't give the car a lot of time to warm itself.

The house was literally on the wrong side of the tracks from campus. The grade crossing had a set of warning lights and bells, but no barrier. To make matters worse, just down the track and around the corner was a small switching yard. Whenever cars were moved around down there, the bells clanged and the lights flashed, but there was, in fact, no train coming.

After a time, those of us in the know adopted a seemingly rational strategy: Approach the tracks, stop, look both ways, and if there was no train in sight, boogie across.

The only problem was, no one had explained to the stove-bolt Chevy the “boogie” concept, especially when cold. Satisfied that the warnings were the usual false alarm, I revved the engine and started across the track. The engine went, “rrrrroooouuuggghhhhh, chug, chug, cough, cough,” and expired, neatly straddling the railroad track. That's when I heard the dreaded “WAAAAAAAHHHHH” of a diesel locomotive. This time, those clanging bells and flashing lights weren't kidding. The behemoth coming around the corner was no switch engine, and it was moving fast.

Did I mention that the headlight on those old diesels was about 12 inches in diameter, and very, very bright? Norman and I learned very quickly that “deer in the headlight” feeling.Norman took the situation harder than I. It was his window that seemed full of train headlight. Norman was reduced to making little “uh .. uh” sounds as he pointed superfluously at the locomotive.

Now here's the important part. I obviously had to restart the car. Either that, or bail, and while I was perfectly willing to do that, I had very little confidence that Norman was in a frame of mind to do the same. But I also knew that the car still demanded that starting drill.

So what do you do when something needs to be done quickly, but the process takes a certain finite, irreducible amount of time? You get it right the first time. This is no time to improvise or cut corners.

Since I'm writing this now, it's safe to assume that things came out alright. As Norman began to drool, I went through the starting drill as carefully and methodically as I ever have in my life. True to our contract, the car roared back to life. I kept the revs way up as I eased out the clutch, and the car cleared the tracks with about 100 ft. to spare.

There's a message here. As professionals, we all know the rules about software and system development. We know that design comes before building, that unit testing is paramount, that desk checking, requirement specs, reviews, etc., are absolutely essential. They're essential for any software project, but even more so when the schedule is tight and resources are limited.

But when you're staring into the glare of that great headlight called ship date, it's oh so easy to start skipping steps and begin hacking, especially if your customer or your boss is standing nearby tapping his foot.

But, as with the Chevy starting drill, skipping steps is precisely the wrong thing to do. If there were ever a time to do things very methodically and precisely, this is it. I used to have a poster over my desk–I wish I still had it. It read,

If you don't have the time to do it right, where are you going to find the time to do it over?

Knowing all the rules of good engineering practice doesn't do you much good if you only practice them when there's plenty of time, and not much to lose. The trick is to keep your head and follow good practice, especially when that headlight is bearing down. It's my firm belief that the fastest way to bring a project in is to do it by the book. Shortcuts and hacks might seem good for the nearest deadline. But you'll find yourself stuck in testing forever, playing “do-over” for all eternity.

When the pressure is on, and people are screaming at you, it takes a certain amount of courage and self-discipline to do things by the book. Nevertheless, that's exactly what you must do. As painful and as stressful as the situation might be, it's going to hurt a lot worse if you allow yourself to get stampeded into doing foolish things and taking foolish shortcuts. Missing deadlines can be hazardous to your health and your professional career. But taking foolish chances can be far more so. The best strategy is to grit your teeth, focus on the drill, and get it right the first time.

Before I leave this story, I have one confession to make. Yes, it's true, I grit my teeth, focused on the Chevy's starting drill, and got it right. But hey, I'm no dummy, either. While starting the car with one hand, I had the other on the door handle. I had picked out a spot on the track. When the train got there, I was out the door. The Chevy was going to have to fend for itself.

So was Norman.

Jack Crenshaw is a senior systems engineer at General Dynamics and the author of Math Toolkit for Real-Time Programming. He holds a PhD in physics from Auburn University. E-mail him at jcrens@earthlink.net. For more information about Jack click here

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.