Bike-shedding: how mature are you as an engineer?

This blog post is all about ... designing nuclear power-plants, insatiable desire to put CQRS, eventsourcing & microservices in every software product, engineers' maturity, what's more important: problems or solutions &...

3 months ago

Latest Post On Meditation. And Mindfulness. by Sebastian Gebski
This blog post is all about ... designing nuclear power-plants, insatiable desire to put CQRS, eventsourcing & microservices in every software product, engineers' maturity, what's more important: problems or solutions & how JIRA can help (yikes!).

There are some terms in IT you'll probably never learn at any CS University course. Yet, they are too important to omit & one of them is "bike-shedding". Frankly, I haven't heard this particular term until last year's outstanding presentation by Jimmy Bogard.

But let's assume that for whatever reason you haven't so far & don't want to watch Jimmy's vid. Basically ...

Bike-shedding happens when instead of dealing with real problems that are very hard to tackle & possibly out of your comfort zone, you focus on completely unimportant details - just because you know how to deal with those or they are somehow more appealing to you personally.

It's a well-known metaphor of so-called Parkinson's Law of Triviality, that is usually illustrated by very amusing, but probably fictional example of committee working on the design of a new nuclear power plant. According to this urban myth :) the overall task was so overwhelming that committee spent half of the projected time on ... designing such a meaningless, trivial detail as bike-shed for power plant's crew ...

Regardless whether it really happened or not, don't we encounter such situations every 2nd day when building software?

Jimmy nails it great in his presentation, I can only continue from when he stopped ....

Freaking nightmare for anyone with a basic ability to think pragmatically.


Obviously there are several reasons behind all of that:

  1. we mistake engineer's MATURITY with her/his proficiency to write code we need - and at some point we believe that the former just came with the latter, while in the fact these two develop independently & frequently with different speed
  2. so many companies treat Software Engineers as monkeys to turn specifications to syntactically proper code - no surprise that devs quickly get bored & start "masturbating with tech novelties"
  3. we're too used to jumping straight into SOLUTIONS, while in fact we should always start with factual PROBLEMS (which sometimes really requires some deep diving with subsequent "why" questions) & learn to comparatively prioritise them

OK, these 3 points can be addressed directly (once you've reached certain level of awareness) - is there anything more that could help in fighting off the "bike-shed effect"? Here are few ideas/techniques:


This may sound like a trivial & obvious topic, but I wouldn't treat it too lightly. Bike-shedding is detrimental to general engineering culture - it affects focus, engagement, effectiveness & in general brings a lot of frustration (when you notice that a lot of activity brings no tangible effects ...).

What is worse, it's one of those issues that frequently are not noticed until it's too late ...

Sebastian Gebski

Published 3 months ago

Comments?

Leave us your opinion.

Subscribe our newsletter

Recieve news directly to your email.

No Kill Switch © 2018.