The Code Whisperer

There’s an excellent bit in the BBC’s Blackadder goes Forth comedy series where Blackadder is being court marshaled for shooting the general’s pigeon and due to a mistake the hapless, but enthusiastic, George is defending him.

Blackadder: George, I’m in trouble here. I need to construct a case that’s as watertight as a mermaid’s brassiere. I’m not sure your particular brand of mindless optimism is going to contribute much to the proceedings.

George: Well, that’s a shame, sir, because I was planning on playing the mindless optimism card very strongly.

How often do we see this going on in a project?

Generally I’m a positive thinker, bordering on optimistic, but I have a natural urge to plan fully, whether it’s a software project or a weekend away, which reduces the amount of time wasted sorting things out that could have been done before.

So is optimism a bad thing? I’ve always viewed positive thinking as a good thing I feel better when in a positive mood. Somewhere there is a line between positive thinking and optimism (I’m assuming blind and mindless optimism is at the far end of the scale!), but I don’t know where it would lie. A recent blog entry by Alex Shalman titled 8 Reasons Why You Shouldn’t Always Be An Optimist. Personally I think the posting has been written from a pessimist’s view of optimistic people around them, but there is one of the eight that is familiar:

Breaking deadlines. An overly optimistic person will think it takes them way less time to complete an assignment than it really does; they do this all the time! How do you think this affects their co-workers, friends & family, and the general population?

The thing is I don’t think this is only the overly optimistic people that do this, more often than not developers underestimate the time required to carry out a piece of work, particularly if it’s a change or fix to an existing system or it’s using leading edge technology simply because so much is unknown. We then end up with too tight deadlines, which are either missed or heroics come into plan, neither of which are a good ending.

We will look at planning in a later blog, but under these circumstances we should be constantly evaluating the plan. That way we find out we are going to be later early on, allowing more resource to be added if it will help (but see Adding People to a Late Project) or plan to deliver late. I was looking at a broadband driven alarm system last night and the company made the statement about a feature that had been requested but wouldn’t be included in the next release of the software as they didn’t want to delay the release and “…wouldn’t release software that wasn’t ready just because it was due…”. Sensible words indeed.

In Code Complete Steve McConnell makes the distinction between wishful thinking and optimism. He classes wishful thinking as “It’s closing your eyes and hoping something works when you have no reasonable basis for thinking it will”. A bit like when two people are discussing an event, that could go either way and one says “I’m sure it will be OK”. How would they know this?

I agree with Steve. Wishful thinking is beyond blind optimism and has absolutely no place in the management of anything, but, regrettably I’ve seen too many examples of this over the years. If you witness either wishful thinking or blind optimism in play, question it and then do all you can to turn it into a constructive, useful plan.