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 ....
- endless discussions on "design purity & cleanliness" (that e.g. lead to creating pass-through layers)
- premature optimisation of code that's gonna be called twice a day & takes about 200 ms
- introducing new conventions for the sake of using a pattern (because someone has written a blog post about it)
- distributing stuff that could easily work within one, lightweight process (because MICROSERVICES)
- insatiable desire to use a particular new library/technology/framework/tool - because it's the new sexy thing on the web & "it will elevate us to the level our competition can only dream about"
Freaking nightmare for anyone with a basic ability to think pragmatically.
Obviously there are several reasons behind all of that:
- 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
- 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"
- 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:
- proper backlog management - either one backlog (as a place where "work items" come from) or few, but with a clear rules for capacity pool split; why is that important? it simplifies the prioritisation a lot: you don't need to quantify the priorities, you do it by item-to-item comparison
- all work made fully visible - e.g. in a project mgmt/ticketing system; why is that important? makes governance much more easier
- don't be afraid of experiments, but make them manageable -> limit WiP for experiments, for each of them clarify the goal, make it clear that outcomes & conclusions need to be documented & validated against the goal, etc.
- make "facts >>> opinions" one of your key ground rules (slap it on your wall!) - helps to cut the crap out
- always, always, always reverse-engineer solutions brought up back to problems they are supposed to solve (or risks to mitigate, opportunities to explore) - the more quantifiable they are, the better
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 ...
