Poul-Henning Kamp

Isn't bike-shedding when other people block you with low-effort critisism.

""" Parkinson shows how you can go in to the board of directors and get approval for building a multi-million or even billion dollar atomic power plant, but if you want to build a bike shed you will be tangled up in endless discussions.

Parkinson explains that this is because an atomic plant is so vast, so expensive and so complicated that people cannot grasp it, and rather than try, they fall back on the assumption that somebody else checked all the details before it got this far. Richard P. Feynmann gives a couple of interesting, and very much to the point, examples relating to Los Alamos in his books.

A bike shed on the other hand. Anyone can build one of those over a weekend, and still have time to watch the game on TV. So no matter how well prepared, no matter how reasonable you are with your proposal, somebody will seize the chance to show that he is doing his job, that he is paying attention, that he is here. """

https://bikeshed.com/

Yak-shaving comes to mind, but that is more when you have a large boring project you have to get through first in order to get to the interesting parts.

Thanks for the link. It wasn't clear to me, however, who was doing the bikeshedding.

If you read the original source for the term at http://bikeshed.com/, Kamp shows his respect for the submitter of the change:

I bow my head in respect to the original proposer because
he stuck to his guns through this carpet blanking from
the peanut gallery, and the change is in our tree today.
I would have turned my back and walked away after less
than a handful of messages in that thread.

This is how I feel about the pull request: a seemingly innocuous change that looks, to this outsider anyway, well worth making. It seemed to have been declined over a concern that people would come to expect Rails to formalize undocumented behavior that others had relied on. I've been consuming Rails docs for years (thank you to the contributors), and that doesn't seem that crazy to me.

(Edit: formatting.)

> but the committee meetings aren't expensive. They are basically free. And there often should be far more of them. The real cost comes from major changes in the design too late in the project plan.

https://en.wiktionary.org/wiki/bikeshedding

> The term was coined as a metaphor to illuminate Parkinson’s Law of Triviality. Parkinson observed that a committee whose job is to approve plans for a nuclear power plant may spend the majority of its time on relatively unimportant but easy-to-grasp issues, such as what materials to use for the staff bikeshed, while neglecting the design of the power plant itself, which is far more important but also far more difficult to criticize constructively. It was popularized in the Berkeley Software Distribution community by Poul-Henning Kamp[1] and has spread from there to the software industry at large.

http://bikeshed.com/

I've written CSS for over 10 years, and I don't use preprocessors at all. I've written small web pages, e-commerce sites, enterprise applications with tens of thousand users. And I find it really offending that you think this is because of lack of experience.

I don't care about mixins, variables, a few instances of duplicated code and my clients doesn't care about any of the code under the hood. In fact they care about time to market, and that is something I am exceptionally good at in my area.

In fact variables has always been possible with multiple class names.

The discussion about what we should choose between traditional CSS, SASS and LESS is on the same level as what color the bike shed should have. http://bikeshed.com/

Pick one and be happy, neither is better or worse. When you're building web applications, CSS is least of your problems.

This sounds like the in-house equivalent of The Oatmeal's "How a Web Design Goes Straight To Hell" (http://theoatmeal.com/comics/design_hell).

Both stories share a similar problem: a designer (or engineer, it doesn't really matter for this story) is brought in because their expertise is needed. Then, rather than trusting that experience, the thing is micro-managed to the point where it is ridiculous (or, as The Oatmeal says, you are just a cursor in a graphics program, controlled via email). I feel that with design this happens more, because it's more tempting to believe that their own user experience is representative of anything more than themselves (the first thing a proper designer knows NOT to do) and it's easier to get into bike shed discussions (http://bikeshed.com).

I'm bookmarking this, because I might need it in the future.

All these "constantly challenge your own assumptions" prompts really do in practice is make it second guess assumptions that actually are obvious and true, which pollutes the output further.

In a sense, it bikesheds[1] itself. It's been told it needs more discussion/debate to solve a problem, but it's only smart enough to tackle minor details that might not matter. And when it does try to tackle major details, it screws them up, causing a cascade of compounding bullshit. And it also tends to cause it to roleplay someone who constantly bungles things, which is bad because it takes it away from its default RLHF tuning for factually accurate outputs on first shot (not that it lives up to this goal, but that's how they've tried to train it).

Getting this right seems to be a very tricky problem.

1: https://bikeshed.com/