In October 1999, Poul-Henning Kamp sent an email to the FreeBSD mailing list with the subject line A bike shed (any colour will do) on greener grass.... In that long note, he explained Parkinson's Law of Triviality, which is also known as bikeshedding or the bicycle-shed example.
First coined in 1957, Parkinson's Law contrasts building a nuclear power plant to building a bike shed. Kamp's email message summed up the law, saying, “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.” As Kamp explained, a bike shed is easy to build, especially when compared to a power plant. “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.”
At the time, Kamp was working on the FreeBSD Core team, which is the operating system’s governing board, and saw a pattern repeating itself. “Somebody wanted to do something, and a lot of people found a way to 'contribute' by bikeshedding any attempt at action,” Kamp says. “The more trivial and easily understandable, the easier it was for them to kvetch, and the more they did.”
Because of his position in the FreeBSD project at that time, Kamp was particularly annoyed by the pattern he was seeing, which is why he sent his thoughts to the email list. “You see it in politics, from national to school board and boy scout meetings,” he says, adding, “You see it in pretty much any meeting in a corporate context where somebody has a ladder to climb.”
Not that this would have any relevance in your life. Oh, no. I’m sure you’ve never seen any behavior like this at all. But play along, because a friend might have experienced “bike shed” moments. Right. A friend.
True Tales of the Bike Shed
“I think my personal worst example was a couple of years before the bike shed email,” Kamp said in a recent interview, “where I sat in a 15-person design review and a 30-minute discussion was summed up with 'OK, make the function return a string and then delete it.'"
Edwin Rothrock, director of sales and marketing at multi-media communications company The World Company, remembers a bike shed moment of his own. It was with a group at a publishing company that was attempting to catalog all of its websites. “The development of an effective taxonomy is a skill,” Rothrock says, “But everyone thinks they know what their readers want and need. So instead of letting an expert design the search terms and get the whole thing up and running, there was a month-long running battle about what words mean. If I recall correctly, we never got the search implemented across all the sites, which undoubtedly contributed to our poor cross-site traffic and eventual demise of the entire group.”
Rothrock also encountered bikeshedding in a more recent position. “Everyone, all the way up to COO, got involved in picking colors for a logo on a product launch,” he says. “It delayed a very time-sensitive launch by almost two weeks.”
Don Marti, a speaker, writer, and web developer, says that many things that look trivial to a programmer might actually be relevant to users and could be vital to the success of your project. “For example, the messages that show up when a user makes a mistake on a website signup form might look trivial. But in actual use, I have seen that simple things like this can affect how many users make it through the signup process.”
Hal Pomeranz, founder and technical lead of Deer Run Associates, a consulting company focusing on computer forensic investigations and information security consulting, recalls Parkinson's Law of Triviality in action from back in the dot-com days, when he helped move a start-up into a new office space. “The marketing department wasted two weeks of an already tight schedule trying to figure out what type of granite to install in the lobby of the new space. Bikeshedding at its finest,” he says.
Too many managers on a big project created a dysfunctional bikeshedding environment for user interface designer Christopher Nemeth. “I often had no clue where my next directives would be coming from,” Nemeth says. “There was the manager I reported to, a product manager, a program manager who was his boss, a VP of the division we were in, the technical VP of the division, the marketing director for the project, and the CEO of the company who had a particular interest in the project,” he says. None of the managers directing Nemeth's design had design backgrounds, but each one knew what he wanted to see.
Every manager also had his own idea about which project attributes was his to nitpick. “Not that they had any idea why – or why not – these things should be their particular specialty,” Nemeth says, “Just that it was what they wanted to have their imprint on. Their 'That was my idea!' moment.” After three similar project cycles, each lasting two months, Nemeth left the company.
“To this day, I am amazed that the company actually can accomplish what it has over the years,” Nemeth says. “But when you throw enough bodies at something until it works the way you want it to – and point fingers in the right direction when it doesn't – you eventually get somewhere, I suppose.”
How to Avoid Bikeshedding
Every seemingly trivial discussion isn't necessarily bikeshedding. For example, sometimes the littlest detail, such as where you place a button on your landing page, can make a huge difference to the success of your project. Also, Marti says, if your project contains data or intends to collect data, such as marketing data, then it's not bikeshedding. In that case, the data really is in the details.
It is the other situations that lend themselves to bike shed moments. “Build and deploy tools are an example of time-suck problems,” Marti says. “I've spent huge amounts of time on dealing with roll-your-own replacements for some commonly used technology.” Marti says that it can be tempting to decide that you don't like something about the Resource Package Manager (RPM, the deployment tool for Linux-based systems), for example, and that you could do something slightly better. “If nobody ever did that, of course, you'd never get better stuff to work with. But it's risky to spend too much time re-implementing something that's not core to your project,” he says.
How do you decide whether you're having a bike shed moment or simply paying attention to the details? Marti says, “You have to compare the state of the alternative where it is now – or [where] you could reasonably get it – against the state of the established tool. You can't base decisions on a future, everything-working hypothetical version of the alternative.”
Remembering the final goal of the project is important, Pomeranz says. “Everybody needs to understand and be able to clearly articulate what the mission is: delivering a software release, getting moved into your new office space, whatever. That will help you focus on what furthers the mission and what doesn't matter,” he says.
“I think this is one of those instances where once you name the demon, you have half defeated him,” Kamp opines. “Having the 'bike shed' concept, we can now stop a discussion by saying, 'This is a bike shed; back to substance,' which is a very different and much less-offending message than saying, 'This is not relevant; stop it.'"
