Why should I care what color the bikeshed is? (1999)
bikeshed.com
bikeshed.com
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.
The very competent can do this without the boss realizing ;) Or it's just a tall tale.
One strategically misspelled word placed somewhere around and neer the lower right of the page…
At least that’s the way some lawyers I know do it.
I also think the idea here is to apply it to bosses who's self-worth seems to be tied to putting their mark on the product without being burdened by knowledge. (Because they'll want to change something regardless of the state)
Comedy sketch writers would write a throwaway that was too off the wall to air, then include it in their proposal among others to make sure their darlings made it through.
I'm also reminded of the story of the Tetris contract in which a revision of the contract had an important change of a few words, and also an increase of some other fee. This fee change stole the attention and hid the other more insidious revision.
A friend's father who was an architect used to do that all the time. He'd submit a drawing that definitely wouldn't pass planning regulations, then go for a meeting with the planning officer and say "Right well how about we swap the swimming pool I am allowed to have, for the dormer windows that I'm not allowed to have?"
Given that even down south here at 56°N no-one really bothers with having a pool, it's an easy trade.
My late father solved the "getting round the planning department" thing by simply being the only person prepared to keep welding new floor pans into the local head planning officer's string of rusty old Opel Manta GTEs...
So if I buy the plot of land in front of yours and want to build my house as a 40-metre tower of rusted Cor-Ten steel with 1kW floodlights every metre or so, you'd be okay with that?
https://blog.codinghorror.com/new-programming-jargon/#:~:tex...
The color of that bike shed is distracting, though. Is it purple or pink?
If you do that, you'd do me a favour.
I could see the same dynamic in reverse when I had to propose stuff to the central tech team at that employer.
Some people will go through great lengths to find a flaw in whatever they look at, and once they see one they will keep asking about it continuously even if fixing it is something very counterproductive.
It is my firm belief that it isn't likely to find a the flaws in anything important (except for the obvious flaws intentionally left that other posters have mentioned) in the scope of a meeting. Once in a while you will by chance, but even if there is a flaw it needs some to look and think. People who think out loud often drive the meeting in the direction they are thinking and if there happens to be something in that direction they will find it sooner - but they miss the other directions others would have gone thinking in because they directed the thoughts of everyone.
I think that is key. A great mentor early in my career pointed out to me: "A" rated people need to work for "A" rated bosses. It's possible to have a "B" or "C" person work for an "A" boss, but when you put "A" people under "B" or (god forbid) "C" bosses, all kinds of problems ensue.
[I've personally experienced that situation only once, and swore never again.]
Actually, I bet you could have an ok workplace with “A” workers under “C” management. Or maybe the “C” turns into an “A” if they manage to hire good people and get out of their way…
But the problem with "C" managers is that they won't judge "A" work as "A" work, won't understand why some of the "A" work is important, and will get in the way of the "A" engineers, making them go down "C" paths.
A "C" level manager brings the whole team down to "C" level and destroys the morale of "A" and "B" workers while they're at it.
An "A" level manager can guide everybody towards "A" level work.
You want something from someone else, at some cost to you. If you let the other party decline something you seemingly want, they have the impression that they're giving up less or are getting a better deal.
It's just compromise. Except you never actually wanted the thing you're compromising on and the ltjer party never cared about. It's just ticking the psychological boxes.
The printed version, should, if dropped on a desk from about a foot, make a thud.
Then write the summary that is short, sweet, to the point, and nothing but glowing.
Every one will just smile and nod and agree with you.
https://philipkdickreview.wordpress.com/2014/06/04/war-game/
[0] https://mashable.com/article/google-maps-origin-story-satell...
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
This point and the article is more interesting than the OP, IMO
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.
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.
If the Convention Manual says all sheds shall be green they'll argue about what shade of green. If it says it should be Magellan Green they'll argue about whether it should be clear coated and what grit should be used to prepare the surface. It never ends. They'll argue about whether the window frames should be the same color etc.
:)
Of course that can only work in a perfect world where spending millions of man hours compiling the ultimate bike shed style guide makes sense.
Or perhaps https://steelblue.bikeshed.com/ .
(For those who haven't seen, the site accepts any CSS color as a subdomain.)
SCNR
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!
Ask HN: How do you avoid bikeshedding? - https://news.ycombinator.com/item?id=30959723 - April 2022 (14 comments)
Why Should I Care What Color the Bikeshed Is? - https://news.ycombinator.com/item?id=29772108 - Jan 2022 (1 comment)
Why Should I Care What Color the Bikeshed Is? (1999) - https://news.ycombinator.com/item?id=12533079 - Sept 2016 (52 comments)
Bikeshedding - https://news.ycombinator.com/item?id=12403557 - Sept 2016 (31 comments)
Why Should I Care What Color the Bikeshed Is? (1999) - https://news.ycombinator.com/item?id=6188408 - Aug 2013 (31 comments)
Why Should I Care What Color the Bikeshed Is? - https://news.ycombinator.com/item?id=1739203 - Sept 2010 (2 comments)
Why Should I Care What Color the Bikeshed Is? - https://news.ycombinator.com/item?id=272246 - Aug 2008 (14 comments)
Why Should I Care What Color the Bikeshed Is? - https://news.ycombinator.com/item?id=25888 - June 2007 (4 comments)
> 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.
What differentiates a good shed from a bike shed?
If my bike is there when I go to it.
This doesn't explain much since you can do that without personally arguing about the colors