Not Waving But …

In Reflections beyond technology Stephen points out that in projects
“denial trumps rationality with alarming frequency!”. This is undoubtably the case. Reality is cold, hard and obdurate. Once it arrives you have to deal with it.

Some people have a habit of leaving bills unopened (or just throwing them away), why do they do that? Do they expect them to get smaller, do they expect the utility company to forget? and yet…

In a software project there comes a point where many, if not all, the development teams know that they won’t make their targets. Everyone has made their commitments, the project looks healthy from above and senior IT management are feeling good about this one.

In the project meetings though, delivery date poker is played, each manager staying in the game with a “yes, we are still on track”; keeping up the fiction that they will hit the date, throwing a little more of their reputation into the pot while hoping for another player to fold and take the blame for the deadline slip.

The game ends when, finally, someone cannot hide it anymore and admits they will not hit their target. The senior stakeholders have to finally accept that the plan is wrong and the project deadline cannot be met. While all the other technical managers breathe a sigh of relief and quietly adjust their schedules to get back in line with reality.

Lying while expecting to be uncovered at any moment is massively stressful. Believing everyone else’s schedule lies while knowing that your public commitments are lies is terrifying. Which is one of the reasons why IT development is still rated as one of the most stressful careers around.

Many managers deal with it by tacitly expecting their reports to lie to them (stacking up those bills). Insulating themselves from fault though plausible deniability, after all “they thought the project was in good shape”. When reality finally beats denial the blame for the slip cascades down through the organisation until the poor guys who finally admitted that there was no chance they could hit their target get the entire blame.

So, why do projects regularly miss their target dates? because, paradoxically, it is in no ones interest to be the first to admit that they will.

In a (rather good) follow up to his red flag pairing post Obie Fernandez thinks I was a “unnecessarily dramatic”. Probably, but what the hell, its a Blog!

Pairing can be a hard sell to a bunch of experienced, effective and productive developers (same goes for TDD actually, but that’s another story). Throwing in “pair programming is one of the only effective ways that a lot of us have ever witnessed keeping average developers from pissing away 95% of their productivity engaging in non-work” really doesn’t help to get their respect and buy-in.

Do I really think they are just “average”? (I don’t)

Do I really think they “piss away 95% of their productivity”? (I don’t)

Do I think they could do better and have more fun and satisfaction Pairing? Yes, that’s the sell, but they are not hearing that because they are too busy seething at being implicitly labelled as average time wasters.