Sandbagging

The System Is Stupid, So Outsmart It!

Rating: 

 Paul Kimmel (view profile)

August 2, 2004  

Introduction

How many of you are working on a software project whose schedule was set by fiat? Or on a smaller scale, how many of you are routinely given tasks and a deadline at the same time by someone that can't do the work themselves?

Pointy-headed Manager says: I hereby decree that we will write the next Internet whizbang, boondoggle, whos-e-whatzits in three months using eXtreme Programming.

Engineer meekly replies: How was the schedule derived without the analysis and feature set and a lot of planning?

Pointy-headed Manager: That's when Sales promised it to the customer.

Brave, Un-savvy Consultant: We haven't got a snowballs chance in hell of achieving all of those goals. We will have to skip the whos-e-whatzits, too.

Everyone has been in a meeting where the pointy-headed manager is blowing smoke out of his southward port, and everyone agrees that the scope is too ambitious and the schedule is ridiculous but no one speaks up, or perhaps someone speaks up and is summarily executed, right!!

Unfortunately, this is the stupid system in which we find ourselves. Managers and sales people promise something and then tell the engineers about it. I say fight back. However, instead of shouting I am as mad as hell and am not going to take it anymore, use your noggin and avoid getting fired.

This article is about wowing your boss, wowing your customer, and winning every single time. I am going to tell everyone the secret. First, you will have to make everyone that can shrink your paycheck as mad as hell, but, only for a moment.

Disclaimer: Everything in this article is legal, ethical, and most importantly smart. However, you must never explain it to any pointy-headed people.

The King Decrees...

The King has just decreed that your project will be done in three months, immediately followed by him telling you what the project is. Everyone in the room can see the King's new clothes are revealing a bit too much of his dimply butt, but no one wants to say anything because his kingship has a habit of lopping off heads.

Hence, the project inception proceeds as always: with unrealistic expectations and no real buy-in. Everyone verbally agrees on a schedule everyone knows will not be made, and everyone knows that the project will slip days, weeks, months, and even years a day at a time. The real goal then becomes how do you as an individual win every single time given these ludicrous circumstances. The answer is that you sandbag.

Sandbagging

In this context, sandbagging means that you take as long as it takes to get to the first milestone. This, of course, will make the King very upset, and you may come close to losing your head. But you won't.

The next thing to do is after you have written, tested, and re-tested the code thoroughly and had someone else double-check, make the King wait one more week. I know your first inclination will be to show the King how brilliant you are, but resist. The King is a bully and besides he is still naked.

As soon as you are sure your code is perfect, tell the King that the new code will be ready in one week. That's right, make that snorting, bellicose, bully wait another week. (Remember, I said you were going to make someone mad right off.)

You're a Code Super-Hero

You have just purchased your breathing room. Immediately start on the next task, but don't make a big deal about it.

You now know that your first deliverable will be delivered as promised in perfect condition in a week. You have begun the long, but worthwhile climb to super stardom. From this day forth, you will deliver everything promised on time and on schedule because you will never promise or announce the availability of something you don't already have. You are sandbagging. (But everyone's blood pressure is a lot lower and work is more fun now.)

Rules Every Sandbagger Should Know

To make it easy for you to remember because you already have enough to worry about, I have consolidated the rules every sandbagger should know into a few simple statements. Here they are:

I want to thrill and please my customers and bosses (but not at the cost of my own sanity). 

I will never make my customer a guinea pig. (It isn't nice to turn people into rodents.) 

I will never promise what I don't already have. (And, I will promise to deliver next week what I have today.) 

I know that perfection is the public face on a lot of hard work. (And, I will never let them see me sweat.) 

Hardware engineers can hide a lot of ugly solder with a nice polyethylene cover, and I promise to hide my ugly code with a nice user interface. 

Finally, Proper Estimating Techniques

No one works an eight-hour day. Even if you are working a hundred hours a week—I hope you get paid by the hour, double overtime, and have an equity position, but—you don't work an eight-hour day.

Everyone makes estimates based on an eight-hour day, yet no one works an eight-hour day. Productivity studies, my own observations, and common sense indicate that people work much less than eight hours per day. So, why do we make estimates based on an eight-hour day? We shouldn't, and now that you are a super sandbagging hero, you know better.

The average day includes trips to the bathroom, pointless meetings, lunch, smoke breaks, trips to the water cooler, e-mail, phone calls, surfing the Web, and all of the other things that keep one sane. People coast over coffee in the morning—that's why there are newspapers in the can. People coast back from lunch, and shoot the breeze as five o'clock approaches, the days get sunny, or on Fridays. And of course, there are martini lunches and Monday hangovers that kill productivity too.

Rather than condemn anyone for being human, accept your nature. Embrace it, in fact. As part of our embracing our humanity, accept its impact on our productivity.

After more than a dozen years as a consultant, and having worked on many projects with people all over the world, I have discovered that the productivity impact is precisely 2.6. How it works is that one should make his or her personal best estimates and then multiply these estimates by 2.6. If, as an industry group, we do this, more projects will be on time and on budget. It is our insistence that eight-hour days exist that causes all of the missed deadlines.

Finally, never tell any pointy-headed persons about the 2.6 estimating factor. The average pointy-headed nincompoop will truly believe they can bully you into not flirting with your wife over IM and that constipation is good for you.

Summary

George Bernard Shaw said that the reasonable man adapts himself to the world; the unreasonable man persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man. What Shaw forgot is that unreasonable men get fired and this makes it hard to pay the mortgage. Businesses depend on reasonable men and can be quite intolerant of Shaw-men.

If you want to win and keep your sanity, sandbag a little. If you are feeling unreasonable, write an article and use a pseudonym.

Biography

Paul Kimmel is the VB Today columnist for codeguru.com and developer.com and has written several books on object-oriented programming, including the recently released Visual Basic .NET Power Coding from Addison-Wesley and the upcoming Excel VBA 2003: Programmer's Reference from Wrox Press. He is the chief architect for Software Conceptions and is available to help design and build your next application.

The Lansing, Michigan area has started a new .NET Users Group. A well-run group offers great learning and networking opportunities and occasionally some free pizza and door prizes. Contact me at pkimmel@softconcepts.com if you live in mid-Michigan and are interested in participating.