Yak shaving sure... but bike shedding is a term I've only ever heard used to dismiss valid criticisms without any counter argument. I've seen plenty of projects where the simplest thing could have made all the difference, but it was hand-waved away as "bike shedding". So the project moves ahead, ignoring any feedback, and then people wonder why the project failed.
I've never encountered someone using the phrase "bike shedding" when it wasn't in relation to a project that was in the middle of failing and the speaker is looking for any excuse to ignore the real reason why. So instead they blame everyone around them for focusing on "trivial" things. How many times was Zune's exclusively brown color and "squirt" feature brought up and dismissed as bike shedding? And when it was released, all the tech press could talk about was that it looked like poop and squirted songs at you.
I can definitely see how it could be used to steamroll over objections, but I don't think that's a problem with the term so much as who/how it's being used. Having a simple term in a team's shared vocabulary to point out when excessive effort is being used on something trivial is important, because it can prevent a lot of time from being wasted.
Here's an actual example from recently: “Hey, I think this parameter [that we can't decide if it should be a boolean or an enum] is turning into a bikeshed.” “Good point, leave it as a boolean for the moment and we can always refactor later.” Something like that is not going to make or break a project, and being able to concisely point that out is useful.
Comments
Yak shaving sure... but bike shedding is a term I've only ever heard used to dismiss valid criticisms without any counter argument. I've seen plenty of projects where the simplest thing could have made all the difference, but it was hand-waved away as "bike shedding". So the project moves ahead, ignoring any feedback, and then people wonder why the project failed.
I've never encountered someone using the phrase "bike shedding" when it wasn't in relation to a project that was in the middle of failing and the speaker is looking for any excuse to ignore the real reason why. So instead they blame everyone around them for focusing on "trivial" things. How many times was Zune's exclusively brown color and "squirt" feature brought up and dismissed as bike shedding? And when it was released, all the tech press could talk about was that it looked like poop and squirted songs at you.
Details matter.
I can definitely see how it could be used to steamroll over objections, but I don't think that's a problem with the term so much as who/how it's being used. Having a simple term in a team's shared vocabulary to point out when excessive effort is being used on something trivial is important, because it can prevent a lot of time from being wasted.
Here's an actual example from recently: “Hey, I think this parameter [that we can't decide if it should be a boolean or an enum] is turning into a bikeshed.” “Good point, leave it as a boolean for the moment and we can always refactor later.” Something like that is not going to make or break a project, and being able to concisely point that out is useful.