See also a rebuttal of sorts [1] from Brett Glass, the sole programmer singled out by name in phk's essay:
> Poul-Henning's assertion that all such ideas should be dismissed as "bikeshedding" reflects this dismissive attitude, which can be just as damaging to a software project as taking too many suggestions (or accepting bad ones). At the time of the discussion I mention above, internal squabbles drove several talented programmers from the project, and I was discouraged from becoming more deeply involved in it. FreeBSD was falling behind Linux in features and in popularity. While it has now caught up in terms of technology, it remains an underdog. This is, in part, due to the developers' dismissal as "bikeshedding" of good ideas that Linux adopted much earlier.
Here is the thing. If you have a Convention Manual which calls for a certain color for bike sheds, then you use that. Failing that, if you have several other bike sheds of a certain color, then that's what you use, for consistency with existing bike sheds.
The color of the bike shed only doesn't matter if it's the only bike shed, and there is no documentation which has already settled the matter.
How boring to have all the bike sheds the same color. I've seen the end result of that - all houses in every direction are 100% identical, both the paint color and the facade in front. I guess they sold them, but I don't understand why anyone would want to live there.
Reminds me of a story a friend related a long time ago about how to manage bosses. That probably applies to bike sheds.
The general idea is to introduce a glaring mistake into any proposal you make. Then the boss (or whoever feels like bikeshedding) can "catch" that mistake upon which you congratulate them on their infinite wisdom, fix the mistake, and the project can move along.
So to avoid the bikeshed color discussion, just do something totally stupid, like not have a roof, or a wall, then the nit-pickers will comment on that, you can quickly "address their concerns" and proceed to have a bike shed of any color you want.
I’ve never done this and I’ve never told my team to do it.
What we have done though, and I will continue to do, js force us to leave things we want a decision on in a clearly broken/prototype state. The number of times I’ve gone into meetings to unblock a team only to have the whole thing derailed by a nothingburger bug that was hard to not see was the inspiration.
if you leave the UI element magenta with cyan font instead of default application style then you’ll actually get a discussion on your UI element.
That could work. It's like a variation of The Dead Cat Strategy.
"The dead cat strategy is a kind of misdirection where somebody will say something so ridiculous or do something so outlandish that it takes your attention away from where they don't want you to look. ..."
In the law school contract-drafting course that I teach, students read about "Combat Barbie" as a way of giving the other party's contract reviewer something to ask to be changed.
> The general idea is to introduce a glaring mistake into any proposal you make. Then the boss (or whoever feels like bikeshedding) can "catch" that mistake upon which you congratulate them on their infinite wisdom, fix the mistake, and the project can move along.
As a programmer who perhaps has a little bit of OCD concerning code quality ;-) when I see such a mistake, I rather tend to dive much deeper into the proposal than when it looks "basically OK", because if there is one such glaring error, in my experience there often are at least dozens. And well, I indeed typically tend to find lots of them in such a situation.
TLDR: Depending on the personality traits of the person who reads the proposal this can be an insanely dangerous game to play.
Just be careful. Paint is very important on a bike shed. If you spend too long arguing you will end up with the weather destroying your bike shed. This was the point, but it is missing something critical.
Color is important even though it serves to objective purpose. Some colors blend in well making an ascetic whole neighborhood better - but even that way can go too far and you get a monotonous mono-tone which is worse than clashing colors! There is - and can be - no agreement on what is best (I'm color blind: I can see colors but not the same way most people do and so even if there was some objective perfect - it would still be different for me vs normal people), but we should spend some time figuring out colors.
The important thing is to give everyone time to think, then express their opinion in a way that everyone else listens to understand (as opposed to listen to rebut) and then we come to a good compromise - understanding letting someone else win is often the best compromise - things like meeting in the middle can be worse!
How delightful, if you click on the picture of the shed it changes the background color of the page and the shed since it's a png with transparent pixels over the shed walls.
24 comments
[ 2.8 ms ] story [ 54.6 ms ] thread> Poul-Henning's assertion that all such ideas should be dismissed as "bikeshedding" reflects this dismissive attitude, which can be just as damaging to a software project as taking too many suggestions (or accepting bad ones). At the time of the discussion I mention above, internal squabbles drove several talented programmers from the project, and I was discouraged from becoming more deeply involved in it. FreeBSD was falling behind Linux in features and in popularity. While it has now caught up in terms of technology, it remains an underdog. This is, in part, due to the developers' dismissal as "bikeshedding" of good ideas that Linux adopted much earlier.
[1] http://bikeshed.info/
The color of the bike shed only doesn't matter if it's the only bike shed, and there is no documentation which has already settled the matter.
The general idea is to introduce a glaring mistake into any proposal you make. Then the boss (or whoever feels like bikeshedding) can "catch" that mistake upon which you congratulate them on their infinite wisdom, fix the mistake, and the project can move along.
So to avoid the bikeshed color discussion, just do something totally stupid, like not have a roof, or a wall, then the nit-pickers will comment on that, you can quickly "address their concerns" and proceed to have a bike shed of any color you want.
What we have done though, and I will continue to do, js force us to leave things we want a decision on in a clearly broken/prototype state. The number of times I’ve gone into meetings to unblock a team only to have the whole thing derailed by a nothingburger bug that was hard to not see was the inspiration.
if you leave the UI element magenta with cyan font instead of default application style then you’ll actually get a discussion on your UI element.
"The dead cat strategy is a kind of misdirection where somebody will say something so ridiculous or do something so outlandish that it takes your attention away from where they don't want you to look. ..."
1 minute summary: https://www.youtube.com/watch?v=U3NvncA_oh0
https://www.contract-rpm.org/#combat-barbie
Can't help but think that getting a good review is also important, not just avoiding friction.
What if they catch the roof, but everyone gets a little tired as the review goes on and they miss some small mistake you actually made?
As a programmer who perhaps has a little bit of OCD concerning code quality ;-) when I see such a mistake, I rather tend to dive much deeper into the proposal than when it looks "basically OK", because if there is one such glaring error, in my experience there often are at least dozens. And well, I indeed typically tend to find lots of them in such a situation.
TLDR: Depending on the personality traits of the person who reads the proposal this can be an insanely dangerous game to play.
This doesn't explain much since you can do that without personally arguing about the colors
Or perhaps https://steelblue.bikeshed.com/ .
(For those who haven't seen, the site accepts any CSS color as a subdomain.)
Color is important even though it serves to objective purpose. Some colors blend in well making an ascetic whole neighborhood better - but even that way can go too far and you get a monotonous mono-tone which is worse than clashing colors! There is - and can be - no agreement on what is best (I'm color blind: I can see colors but not the same way most people do and so even if there was some objective perfect - it would still be different for me vs normal people), but we should spend some time figuring out colors.
The important thing is to give everyone time to think, then express their opinion in a way that everyone else listens to understand (as opposed to listen to rebut) and then we come to a good compromise - understanding letting someone else win is often the best compromise - things like meeting in the middle can be worse!