Personal bike shedding

The concept of bike shedding is one of my favourites, as once you’ve learnt about it, it won’t be long before you see it in the wild at most organisations.

The standard explanation (from Wikipedia), goes like this:

“Parkinson provides the example of a fictional committee whose job was to approve the plans for a nuclear power plant spending the majority of its time on discussions about relatively minor but easy-to-grasp issues, such as what materials to use for the staff bike shed, while neglecting the proposed design of the plant itself, which is far more important and a far more difficult and complex task.”

You might also call this organisational procrastination, or at least see that as a related phenomenon.

I also notice that you don’t need more than one person for bike shedding to occur. It’s similar to commonly observed procrastination, but it can be a little more revealing to think of it in similar terms to bike shedding.

For example, it’s easy to spend a lot of time fiddling with the design, choosing icons and making tweaks to side-issues on a project. Choosing programming languages and technologies falls into this bucket. It goes beyond “productive procrastination”, as it is genuinely necessary work on a project that needs doing at some point. You can’t say you’re not making progress on the project while doing this kind of thing.

However, it’s a form of bike shedding, as those things are relatively risk-free in terms of expected results and emotional responses. They let you avoid doing the truly important bits of the project, such as the core business logic. Like the nuclear power plant planning committee, you might be avoiding the important stuff precisely because it is important – if you get it wrong, or discover that it is harder than expected, it feels like that could derail the whole project.

It’s psychologically safer to tweak the colour scheme, but you must take the risk of working on the important stuff to get the real reward.