Always define the scope of a discussion laser sharp in advance. “This is outside of the scope of this discussion/decision” becomes your jolly joker. It also does not hurt to put an “escape hatch” in any design. For example if you design a JSON schema, add some kind of support for optional extensions. Everyone will come up with use cases that would need that escape hatch, but almost none will be actually implemented in practice.
Ask HN: Strategies to rein in or prevent bikeshedding?
21–27 of 27 posts
Re: Ask HN: Strategies to rein in or prevent bikeshedding?
#22When someone is bike shedding you need to show how trivial what they are talking about is. "Oh it won't work because it will break xyz" "Okay so what does it take to fix xyz?" "maybe a day or two" "..." "It's going to cost more to have xyz" "Oh how much more?" "$100 a month" "..." "It should be blue instead of red" "no customers prefer purple" "alright we will defer this to product team / customer feedback" That bein…
I wonder if this is why there's a rise in A/B testing. We normally see very minor differences, like about 54% vs 46%, but we spend a lot of engineering effort collecting, storing, comparing this data. It seems like something we should just flip a coin over, but I guess it's an anti-bikeshedding method.
The best way to prevent bikeshedding is to make it really easy to try out different colors and measure them.
As the engineer who's been in the "touch nothing" camp before, it's always because the risk/reward of making big changes to bad systems is really skewed towards things breaking and making me miserable.
Re: Ask HN: Strategies to rein in or prevent bikeshedding?
#23Bike shedding occurs when the decision makers are not the stakeholders. People will naturally ignore the challenges and focus on things trivially convenient when they have nothing to lose.
Your solution then is to impose ownership onto the people providing input, with all the liabilities and rewards that entails. Failure then mandates severe penalties. If that is too much of a risk then simply remove their ability to provide input and replace it with a top-down managerial decision absent their input.
Re: Ask HN: Strategies to rein in or prevent bikeshedding?
#24For non-US English speakers,
Bikeshedding: Futile expenditure of time and energy in discussion of marginal technical issues
Re: Ask HN: Strategies to rein in or prevent bikeshedding?
#25Earlier quoted context omitted.
I wonder if this is why there's a rise in A/B testing. We normally see very minor differences, like about 54% vs 46%, but we spend a lot of engineering effort collecting, storing, comparing this data. It seems like something we should just flip a coin over, but I guess it's an anti-bikeshedding method.
The best way to prevent bikeshedding is to make it really easy to try out different colors and measure them. As the engineer who's been in the "touch nothing" camp before, it's always because the risk/reward of making big changes to bad systems is really skewed towards things breaking and making me miserable.
I mean I feel like the process of doing A/B testing is what leads to bad systems. At the very least, you have to build path A, path B, and the null path where the A/B testing system goes down. It's a lot of work to let people change colors, far more if it's something like navigation or a new dialog. And it gets exponentially complex with more of these.
Re: Ask HN: Strategies to rein in or prevent bikeshedding?
#26imo that dev should be served with a pip, which means if you dont get your act straight you're about to get fired.
deadlines means cutting down the spec. cutting down the spec means having to make decisions to release before the deadline and moving all the overthinking to the next iteration.
Re: Ask HN: Strategies to rein in or prevent bikeshedding?
#27When someone is bike shedding you need to show how trivial what they are talking about is. "Oh it won't work because it will break xyz" "Okay so what does it take to fix xyz?" "maybe a day or two" "..." "It's going to cost more to have xyz" "Oh how much more?" "$100 a month" "..." "It should be blue instead of red" "no customers prefer purple" "alright we will defer this to product team / customer feedback" That bein…
[flagged]