This morning on twitter my friend Esther Schindler linked to the article "
Hard Deadline" from the Daily Worse Than Failure. It is the semi-fictional account of the contractor brought in to complete a project of some depth. By the end of the interview the hiring manager is saying nonsensical things like "When can you have it done? We need it by March 15th."
Ideally this would be humorous -- especially when we are far enough away from it to avoid the consequences, but the truth is this kind of thing is tragic for our industry. Someone on high decides something has to be done, a date gets picked, and instead of
estimation, we find ourselves doing
negotiation.
There are some very real reasons bosses do this. First of, all
it works. A good boss, who knows the problem domain well, who has seen a few releases, can often guess an aggressive date, and have his team deliver something close to the original scope, somewhere around the original date. The problem is what happens when
underclassmen see a senior doing a move like this -- they get promoted into management and try it in their departments. Again, the results are tragically hilarious, but if you're in the moment, sometimes it's hard to see the humor.
Secondly, it's an easy short-cut. Throw out a date, and, if the staff laughs at you, you know the date is no good. If they breathe a sigh of relief, you know you've got to find an excuse to add more features -- what you really want (with this immoral strategy) is to have the staff be
just a little bit worried. (This is not my insight; Tom DeMarco outlines this strategy in depth in his essay "
Why does Software Cost So Much?")
Third, non-technical leaders use the make up a date strategy because we, the technical folks, have given them nothing to go on. Why, I remember talking about this problem a few years ago with a friend, and he said "that's why I prefer to never, ever give an estimate. I'll offer to get back to them on it, or know more next week, etc, until the project is at least two-thirds done."
That approach really bugged me; it felt just as weasely as the CFO making up the date, but on the technical side -- and I can't help but notice that that developer was never entrusted with a leadership role on a large project.
There are plenty of good ways to scope problems, develop incrementally, and come up with estimates. The issues I'd like to talk about today -- for just a minute -- is the bald-faced lie presented as reality.
Oh, the people promising March 15th don't
want to be liars. They want to believe that everything will turn out right. They are under i
mmense pressure to make things turn out 'right.' Yet they haven't internalized one of the lessons we hope to give all our children before they leave the nest:
Wishing so won't make it so.
Dealing with these sorts of things is hard.
If you tell these people "I'll try", they will interpret that as a firm commitment.
If you say "we won't hit the deadline", they'll find a way to mis-understand you. They'll say something about how they have confidence in you, not to worry, and walk away thinking they have actually fixed the problem.
At the next status meeting, they'll bring the issue up like the conversation never happened.
In the mean time, during the project, you will likely get a bad annual review, something about not being a team player.
In the worst cases, if you look at the powerpoints that go up to senior management, you'll find any trace of doubt or error wiped clean from the documents.
In these kinds of organizations, it's better to be
certain and wrong than to be
uncertain and right.
Advice for these situations is rare and far between. I've written a few articles, perhaps most noticeably one on
answering unfair questions and a talk that
mentions setting boundaries, but there is a lot more work to do.
But there is good news.
The Good News
Last week I was sent an early draft copy of
Clean Coder, Robert Martins book on software professionalism. The book contains a list of possible 'pitfalls' for the technical worker, including the ones outlined above. More that, though, it provides conversation examples -- what to say, how to say it, when to say, and what to do if the boss responds with this, that, or the other.
This is a practical advice for taking our professionalism to the next level, and it's stuff we just don't talk about enough.
That said, bear in mind:
Clean Coder is focused on the developer, so it doesn't include some common testing tradeoffs. I mean, sure, we could always 'just' test for an hour and call it done -- but I can put plenty of coverage in my articles here and on the web. For a good introduction to the basics, I strongly recommend this book.
It's available for preorder from Amazon now. Despite the title, I recommend it for just about any knowledge worker struggling with the word 'professionalism' and how to respond to the inherent conflicts of interest in our field. Check it out.