[bearjaws]

When 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 being said, people who bikeshed a lot are pretty terrible to work with, they are usually the ones first to tell you how hard a change is going to be and why we shouldn't do it. They would rather do nothing and stay in their comfort zone. Toxic to work with, fire if they cannot change.

[muzani]

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.

[SR2Z]

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.

[muzani]

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.