Bike shedding Triviality in software development

Bike Shedding

The tendency to give disproportionate weight to trivial issues of a larger or more complex project. In other words, prioritizing something easy to grasp and/or is debatable.

Origin and Explanation

Parkinson used the example of a committee meeting discussing ways to finance three projects:

• A £10 million nuclear power plant.
• A £350 bike shed.
• A £21 annual coffee budget.

The meeting starts with members discussing nuclear energy, but most are ill-informed and the project seems too complex to facilitate meaningful discussion. The committee then moves on to the bike shed and since many ride to work, there is more animated discussion regarding its financing. Lastly, the coffee budget is discussed. Everyone drinks coffee, so the colleagues spend the rest of the meeting talking about their favorite blends and the allocation of just £21.

At the conclusion of the meeting, nothing of significance has been achieved.

Parkinson summed up the results of the meeting by defining his law. Parkinson’s Law of Triviality states that the amount of time devoted to a task is inversely proportional to its importance. In other words, organizations devote large amounts of time to tasks that bear little significance to their bottom line.

Indeed, bikeshedding is a pervasive and well-entrenched problem in most businesses. A seemingly infinite amount of time is spent replying to emails and sitting in meetings that don’t seem to accomplish much. Ultimately, these somewhat menial tasks consume resources that could be better directed to major projects with a greater potential to move the company forward.

Common examples of bikeshedding in Software development

One of the common exmaple of bikeshedding is focusing too much on looks of end product instead of effect, behaviour of the project.
Stakeholders spend most of their time, mental effort and meetings trying to achieve visual needs of a project instead of focusing on vision, its impact, and answering how and why regarding requirements.

Process should probably start with good experience (without visual cues and colors) and that should leads to features development and later aesthetics should be handled based on user psychology and keeping end users characteristics intact (total users, age, country, gender) etc.