Published 11/16/2007

The nuns at Holy Redeemer elementary school on Long Island taught us that lying is a sin. As we got older they added a certain amount of nuance to that, differentiating between venial and mortal sins, but the injunction to stick to the truth never waivered.

Adulthood showed that there were more than two shades to honesty: some things are indeed private, and sometimes kids need a carefully modulated version of the truth. But the nun's basic precept has, in my experience, been a pretty darn good guide to behavior: don't lie.

All of us know this. All of us, except campaigning politicians, practice it with a good degree of rigor.

Except when it comes to creating engineering schedules. When I talk to engineers about creating schedules, someone always responds "yeah, but."

Yeah, but the boss will cut our schedule in half.

Yeah, but the show drives the schedule, not any sort of engineering realities.

Yeah, but they'll agree to our timeline but will pile on more functionality throughout the project, all without changing the end-date.

So, many developers give up in disgust and agree to whatever the boss demands, knowing fatefully that it will slip, maybe by a lot. Or they double their real estimate to come out even when management whacks months off their projection.

I think that's a tremendous mistake. Don't lie. Work from the highest of ethical standards. Create an accurate, detailed, schedule and present that.

In my experience most engineering managers are ex-engineers. They love numbers. Yet too many of us present schedules devoid of detail. It's hard to argue against a tightly-reasoned schedule that's accompanied by detailed work breakdowns. Once, arguing this point in a class of 80 developers, all of whom were issuing "yeah, buts" at a machine-gun rate, their VP of engineering stood up and told them: "you never give me these sorts of details, so of course I don't believe you. Give me the numbers and I'll have to yield."

Of course it is true that plenty of bosses will not be swayed no matter what arguments we present. Many honest schedules will fall on deaf ears. But it seems to me that we have an obligation to be truthful regardless. We must collect actual data to compare against projected dates when the project is done, so both we, and the boss, can learn.

Yes, it is somewhat na‹ve to expect management to suddenly have the scheduling scales fall from their eyes when presented with well-supported schedules. But by being dishonest we play their same game. And that's just plain wrong.

Yet an awful lot of engineers disagree with me. What's your take?