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.
Personal bike shedding