March 4, 2008

...Learn TDD with Codemanship

The Elephant In The Room

One of the problems with being a consultant, and trying to help organisations change for the better, is that - bet your bottom dollar - the key barriers to change will sit with the people who hired you in the first place.

Management are the root of 99.9% of obstacles to organisational excellence. Find a problem, pull the string and trace it back to its root cause and you'll normally find a manager sitting at the other end pulling in the opposite direction.

But from their lofty perspective, all the problems seem to start at the bottom with the people who are supposed to implement the manager's vision. They don't do as they're told. They give incorrect estimates. They deliver late. Their code is buggy. They have low motivation and a surly attitude.

And when the manager is the person signing your timesheets, it's all too easy to subscribe to their point of view and set about the developers with a big stick.

But, as always, there are two sides to this story. It's like the way we in the west perceive the global threat of terrorism. These extremists hate our freedom and democracy. They have no regard for human life. They cannot be reasoned with. And so on and so on. But when we take just a moment to see things from the "terrorist" perspective, often we discover that these are desperate people reacting to our inhuman treatment of them and their people.

The same is true of the management-developer stand-off. Take a moment to see how things look from the code face: developers don't do as they're told because the plan or the blueprint is often impractical or unworkable. They give poor estimates because estimates are just guesses, and guesses are ballpark at best. That's just reality biting. Nobody in the world has found a way around that. Be fair, now - you can't point the finger at a group of people because of their lack of precognitive ability!

And if you turn their guesstimates into solid commitments then you must expect to be disappointed. If you build your business plan around a guesstimate, then you are essentially spending your lottery winnings before the numbers have been drawn - which is your error, not theirs.

And about those bugs: in my experience, developers want to build code that works, and want to apply the practices that lead to fewer bugs. It's pressure from their managers that often forces developers to drop those practices and resort to code-and-fix development to create the illusion of productivity when schedules slip. And, after all that, if you crack the whip and wag your finger at them, you must expect that you're not going to get service with a smile.

This is the converse reality that many managers are unable to see, and that consultants like me must try to help them understand. But managers have the power to hire and fire consultants. Which is why in many of these organisations change will never happen. The elephant in the room has the authority to remove anybody that tries to point them out.

Which is a shame, because on those rare occasions when managers have that epiphany and recognise the role they're playing in the cycle of pain, they can make positive moves towards real and lasting change, and become truly great and inspirational leaders. And teams of empowered and motivated developers, working with empowering and inspiring leadership, is a sight to behold.

I see that potential every day. It breaks my heart to watch it being wasted.



Posted 10 years, 4 months ago on March 4, 2008