At some time I realized that I got a gold badge on SO for an answer to non-technical question. My other activity does not attract such attention and does not get such appreciation. I do not participate in discussions not related to programming and non-technical, so I do not hope I'll get close to S.Lott's rep (or Jon Skeet's, for instance)...

Too much discussion is bad. But I think there should also be room for abstract discussions. There is lots of space in the virtual world. Just categorize everything so that technical issues are one things and abstract discussions other things.

Before you can build something, you need to design it. And before that you need the customer requirements and analyze them. Also some people like to talk about ideologies and whatnot. And they will talk about them, if not here then somewhere else. If people close the discussion because "it is not programming related", then the discussion will move somewhere else.

I've seen the same effect in statistics. People will argue endlessly over points that are easy to understand but not that important. It's a variation of the old story of the drunk looking for his keys at night under a lamp post. When someone asks him whether he lost his keys there he says no, but he's looking there because that's where the light is.

Isn't this whole blog a discussion about coding? Ditto SO?

:D

"After six solid months working on the Stack Overflow codebase, this is exactly where we are. We're digging in our heels and retrenching for a major refactoring of our database. We have to stop working on new features for a while and pay down some of our technical debt."

Yeah, it's really hard to see what those "astronaut architects" are trying to achieve through considered pre-code design. Thank god we can make up terms to mock different approaches though, right?

That is how business works, my friend. Actually for at least half of the features I had to implement in software the last couple of years, the discussion time about this feature was significantly higher than the time later on spent on actually coding it.

I cannot understand this attitude, I'm a coder. If we have a meeting and we keep discussing if this feature should be like A, B, or C, I keep thinking myself "Considering the time we spent already discussing the pros and cons of A, B, and C so far, I could have as well coded A, B, *AND* C already, so we could play around with all three in practice for a week and then get together again and simply vote which one we liked most, making it a majority decision".

But I'm a coder. For the marketing and sales guys it is their job to keep discussing it. Sometimes I think I should not even attend these meetings, do something more productive, wait till they banged their heads enough times against each other and finally just code whatever they have decided upon. However, doing that, I miss the opportunity to present MY POINT OF VIEW on this topic and I miss the chance to shout "Objection" soon enough if I see things start going into the wrong direction (like a solution to a problem is discussed, that may sound pretty nice, but is impossibly ever done within the given time frame and thus further discussing it is a plain waste of time). So I fear I must keep sitting in such kind of pointless meetings the next couple of years, too.

@Whatever

"There are known knowns. These are things we know that we know. There are known unknowns. That is to say, there are things that we know we don't know. But there are also unknown unknowns. There are things we don't know we don't know."

Our original db schema was based on Wikipedia. Turns out what we do isn't quite the same, but there was no real way to know that without *doing* it.

These "bikeshed" questions tend to have more answers - scale the reputation from votes to the number of answers with votes in the question?

About hiring someone with a large reputation, I would want to look at the activity that was required to get that high rep. Is someone just answering questions to get a high rep? Or do they really know their stuff. And even if they know their stuff, do they find it more fun to answer questions on Stack Overflow than do real work? These are tough questions to answer but I feel that are at least pause for concern.

John

Another factor is range of expertise. Many of the highly technical questions are only of interest to a small number of people familiar with that technology. The general interest questions appeal to many more. I know there are only a few questions on SO that I feel qualified to respond to or even to vote on. The board general questions are among them.

Some good points, but I'm not sure if the second half of this post follows from the first.

The bikeshed effect is not about abstractions, but about trivialities. An architectural astronaut would not be debating the shedís color; heíd be trying to come up with a scheme that would allow the shed to be any color the client wanted.

Someone debating the color and material of the shed is too concerned with concrete issues, not abstractions.

One possible flaw with the SO model is that, not only does it attract such discussions naturally (for the reasons you describe), it actually encourages them through the reputation system. Far easier to get rep points through asking or answering the "What is your favourite colour"-type questions, than the obscure, specific programming ones.

"Our original db schema was based on Wikipedia. Turns out what we do isn't quite the same, but there was no real way to know that without *doing* it."

I find that final statement surprising. Was there really no way to know in advance that SO wasnít the same as Wikipedia?

Itís one thing to not waste time debating the color of the bike shed, itís another thing to decide you can simply reuse the design for a garden shed, as theyíre essentially the same thing.

It seems to me that different folks have different styles....
Some people want to discuss a project at very high levels (what are the requirements, what are we trying to achieve, etc..) while others are wondering why we talk so much, keeping us from sitting down and coding.

I'm certain there is a happy medium in-between...
an hour's thought about a key design decision can save days of effort later on if someone would just think about it.

But to be fair, pounding out a prototype early (based on a decision without much discussion) can be quite motivating, so long as there is room for refactoring or redesign.

Go back and read the post on 'technical debt'...
skipping a little forethought is one of the shortcuts that results in debt.

It's simply a matter of reward per effort ratio. Easy questions are easy to answer quickly, you know you're right and a lot of people will see your answer. A lot of reputation points for little effort.

I think you tried fixing this with the bounty but I think there should be some kind of auto-bounty (which isn't taken from the user). The longer the question is alive with no or few answers, the greater the amount of reputation points it should be worth.

@Whatever & Steve - you are making huge assumptions about the knowability of the SO task. In *hindsight* the difference between Wikipedia and SO may be obvious. What should also be blindingly obvious is that your very perception of the differences between the two systems is irretrievably biased due to your knowledge of what SO has become.

Keep in mind, too, that SO has been very, very successful. This is key: the methodology under which SO was developed has proven its wisdom. For all we know, a similar system planned by a group of "Architecture Astronauts" would still be in the conference room hashing out the details of the "User" table. Again, however, your perspective is biased by the *assumption* that the methodology that you propose would have led to a completed and successful system; just like SO but without the "obvious" flaws you describe.

You've got to wonder- does the bike shed really need painting in the first place?

Really good post !

It reminded me to stop reading your blog and get on with my work ! ;-)

Dan

I'm almost positive that last excerpt appeared in "Getting Things Done". I know I've read it before, although this is the first time I've heard it being given a name.

Certainly jibes with my own experience, both at work and in social gatherings. The longest arguments are always about the most pointless topics - methodologies, layouts, colour schemes, branding, religion, politics. The weather.

You still need formal requirements, though, otherwise there's no way to prove your design works.

This is one of the posts that hits the nail right where it should. This is true for simple team discussions where the topics could me mundane and opinions could me manufactured on-the-fly.

Quality controls, appraisal systems, Defect sheet formats, defect categorization and other silly stuff (these could be important and to-the-point discussions for some, but imagine 20 techies discussing them).

Reminds me what made me learn sleeping with eyes open :)

Excellent post. Now I need to get back to getting things done!

I would say that the things you mentioned are better done by one or two. But they should still be done, just sit down and do it!

I totally agree. Anyone who responds to here is "more interested in discussion than writing code." Who are these people anyway?

Oh, wait...

You better make sure your Bikeshed is big enough to hold your bikes though....

And sometimes people can take a discussion that is intended to be focused and technical and by sheer force of will turn it into a bikeshed conversation. Such as when I say "Psh, even I could have told you using Wikipedia's schema as your model was a gross error."

'"After six solid months working on the Stack Overflow codebase, this is exactly where we are. We're digging in our heels and retrenching for a major refactoring of our database. We have to stop working on new features for a while and pay down some of our technical debt."

Yeah, it's really hard to see what those "astronaut architects" are trying to achieve through considered pre-code design. Thank god we can make up terms to mock different approaches though, right?
Whatever on March 4, 2009 04:36 AM'

You stole these words out of my brain ;0)

Ah, that's the term for Human Resources' hour long discussion of what font to use on the "Core Values" poster. I had a much less creative term for it.

Actually, a very fine post...

Yet another timely post. I read this after getting out of an implementation meeting where a vendor asks "What do you want to do with software x?" (that the customer already owns). The customer answers and the vendor essentially tells them the answer is a not the best use of x, and asks the question again, re-explaining the abstact options AGAIN and recycling the discussion instead of working with the customer's needs, making a recommendation and moving forward with a decision.

I agree Jeff, I'm a student at Full Sail University, currently in my final project of the Game Development program. The project we do here before graduating has a 5 month development cycle, of which the first 2 months are devoted solely to design & architecture. Personally it drove me completely nuts to go that long without being allowed to start a code-base.

@Mark

I didnít mean to be critical of Jeffís work. I think SO will be a huge success. I was only questioning the claim that it was impossible to know in advance that a schema was wrong. Jeff said that it turned out that SO doesnít do quite the same thing as Wikipedia, not that the requirements of SO changed. Without making any assumptions about the SO design process, it seems at least possible to anticipate how the db would be used.

If Jeffís comment had said that they decided to use an existing schema as it was important to get the product out the door asap, and knew they could refactor it later (ie technical debt), or if heíd said the requirements had changed since the initial launch, it would have been quite understandable. But saying there was no way to know what the requirements were before writing it seems an odd statement.

Note that Iím not criticising any of the decisions made in producing SO. Pragmatism is an important, possibly the most important, part of any business, and if that means taking short cuts to getting the product out of the door on time, then so be it. The only real test is the bottom line.

Let's get down to brass tacks. What can you do to avoid or stop these discussions? What if you defer to the other party and they want to paint the bike shed pink polka-dots? A trivial question can turn non-trivial if it's answered so badly as to incur lasting damage to the project.

Here is a site you can find free open source books. "Producing Open Source Software" is also in also part of the list:

http://www.onlinecomputerbooks.com/free-open-source-books.php

Ok, I am going to rewrite this... (sorry for the misspellings)
Here is a site where you can find free open source books.
"Producing Open Source Software" is also part of the list:

http://www.onlinecomputerbooks.com/free-open-source-books.php

@Steve W,

"The only real test is the bottom line. "

It's surprising how many people forget that.

If you can anticipate the market then you're right: you're much better off. But you'd be surprised how much it really saves you when you get the future right and how much it hurts you when you get the future wrong.

Just think of this as all part of the design/requirements process and you'll feel **MUCH** better.

Jeff,

That's a great piece of advise (be wary of too much discussion).
It helps to make a decision of how much discussion and abstraction thinking is optimal.

Such decision is not easy. No discussion/abstraction is not effective. Too much discussion/abstraction is not effective either.

What I think is funny about the bikeshed phenomenon is how people will argue and argue for days when building a new bikeshed about all the attributes that a bikeshed MUST have to be useful. But then someone walks into the room and asks "Why are you building a new bikeshed when we already have one over there (points to it)?". Suddenly, everyone unanimously agrees that the existing bikeshed is just fine DESPITE the fact that it has NONE of the attributes that they just spent days arguing that a good bikeshed must have. ;)

Jeff,

I just started reading your blogs recently. All your blogs have been informative and refreshing in their insights.

Here's wishing for more gems from you.

Thanks.

Interesting.

Still, abstract thinking is not entirely useless. You can get down to business and build things as fast and efficiently as you want to, but if what you are doing is fundamentally shit it doesn't matter one bit. Unless you are just in it for the money.

I guess this is why things are split into concepting and work phases.

As always, the world is not binary or black and white. There is room for abstract thinking. Just don't do too much of it. That's always the trick. Instead of doing either pure coding slinging or pure BDUF, try doing JEDUF (just enough design up front).

wow, Bikeshed effect is very useful wisdom to me. thank you.

Why so down on /.?

Stop going to meetings. No coder needs to go to meetings with people who have no basic conception of what he or her does.

Stop answering the phone, both cellphone and landline. No usable coding advice is likely to come from either.

Stop reading your email. At least route mail from everyone outside your work group into the circular file.

If you don't go to meetings, ignore phone calls, and archive all unsolicited email until the end of your project, you might get some useful work done. Otherwise, there seems little chance.

Devil's Advocate Question: Is it possible that sometimes (maybe even most times), the discussion *around* what the code should do is more important than the code?

And what was the point of the mentioned? Giving a group concrete tasks rather than vague, abstract tasks gets better results? Wow, what a surprise! :)

Thanks Jeff, I now have labels, "bikeshed effect," and "architecture astronauts," for phenomena I have witnessed for a long time, but had not recognized as discrete concepts.

"those who thought about the questions abstractly were much more likely to procrastinate -- and in fact some never got around to the assignment at all."

Yep, thinking is hard work.

"I find that the amount of discussion on a software feature is inversely proportional to its value."

I'd say that's the way it often works out if good management isn't in place. The task for a project manager in this dilemma is to motivate the team (and individuals) on issues they SHOULD think about, but at the same time prevent falls into the bikeshed tarpit; the amount of discussion should be proportional to value.

However, I suspect the latter result will come about automatically if management is getting most things right; I'm not sure a manager needs to explicitly deal with "not enough thinking" vs. "too much useless chatter," or "too much high-falutin' abstraction" vs. "not enough concrete work." I'll have to think about that. ;-)

Some of my best and most lasting (read stable, useful and never fundamentally altered) accomplishments in this job were a result of month-long belabored discussions with all parties involved. Of course, the difference was that I came into the discussions with a detailed design complete with the implemented code right in the documents. The discussions revolved around specifics and tweaks which were quite easy to adapt to.

Also, some of my worst failures were around things I spent no time discussing with anybody and just implemented and checked in. We're fixing that sort of thing now.

Additionally, I'm also currently spending a tremendous amount of time redoing things that others spent a month discussing in the abstract, and then somebody implemented it and checked it in.

Is this another "dead tree" (doesn't that phrase become boring to you?) book that you haven't read and this post mixed in with too much psychobabble junk science?

Jeff,

When the problem domain is trivial, like StackOverflow, your blog post makes much more sense.

The implementation may not be trivial (thinking of stack overflow again) - I would not call any code base trivial - but it is quite a different story when the business model is significant. Just what are you going to "sit down and code" ?

In other words, we all know what a shed is. We all know how to paint. And we all know what colors are. So instead of talking about it too much, let's paint the darn shed.

There are many software systems where the software engineers do not know the problem domain they are "coding", so they cannot "sit down and code". For example, implement a control system for an automatic transmission to be embeeded in an automobile's computer. We better talk before we start typing.

Lepto Spirosis: "If you don't go to meetings, ignore phone calls, and archive all unsolicited email until the end of your project, you might get some useful work done. Otherwise, there seems little chance."

You might also miss the news that your project has been axed, half the dev team have been fired, and even without all that, the fact that your implementation of the business process bears very little resemblance to what happens on the factory floor.

If you are the designer of *both* process and product, by all means go and do your own thing. Otherwise as Bill says, we better talk.

"... the amount of discussion on a software feature is inversely proportional to its value."

Isn't this architecture by democracy though?

By simply picking an architecture that "everyone" accepts sans comment you're bound to be choosing some worst of breed thing that any hack is familiar with. While this may seem productive in that any hack is prepared to code to it as well, it may completely ignore scalability, flexibility, longevity, maintainability, etc.

If this were really the goal everything would be a rat's nest of flat PHP/MySQL web apps, damn the customer requirements or business realities.

I used to suffer from Apathy, but now I can't be bothered.

<a href="http://www.instantrimshot.com">http://www.instantrimshot.com</a>

ooh, URL got mangled there... where was that post on URL parsing?

@ Mecki

Sitting down and coding can be fail too. On many accounts it is worth justifying what features go into the system as opposed to just blithely implementing anything that gets near to you.

I'm a big fan of reducing the number of possibilities because that reduces the complexity of the system and hence reduces the number of potential bugs.

Not only do you have to code the feature but you then have to maintain, support and possibly rewrite that feature (when refactoring / porting etc). Is the feature worth all that?

The reason we spend time in meetings is creating software is about satisfying customers, not writing code. If a feature isn't going to satisfy the customer then coding it is _negative_ productivity because of maintenance and support.

Exactly!, why am reading this blog when I have things to do!

+1 Eric > "Go back and read the post on 'technical debt'...
skipping a little forethought is one of the shortcuts that results in debt."

Forget thinking critically, let's all just start throwing stuff at the wall and check to see what sticks...

That's just mental laziness and you end up doing MAJOR refactoring and re-designing, taking up lots of time that could have (at least mostly) been avoided initially.

<< The bikeshed effect is not about abstractions, but about trivialities. An architectural astronaut would not be debating the shedís color; heíd be trying to come up with a scheme that would allow the shed to be any color the client wanted. >>

Not exactly. A normal person would come up with this, because it's a pretty obvious requirement. Client needs blue shed, so it's within the realm of reason that they might want a red shed, and it's cheap, so why not? Most of us can handle that.

The architectural astronaut, on the other hand, would decide that color _just isn't enough_. Maybe, in some alternate reality, the client also wants methods to choose different types and style of shed. Maybe the client wants completely different dimensions, a few windows, a different type of roof, different options for siding material, etc.

But wow, all of this customization is a pain, and gee we have to do a lot of work just to make _one_ lousy shed. So why stop there?! Maybe, god forbid, the client wants a _shed factory_ that can produce any type of shed to meet any imaginable purpose ranging from rusty box in the back yard to an airplane hanger. And if it's going to produce sheds, well shit, let's have this thing make houses, condominiums, skyscrapers, duplexes, big-box retail stores, restaurants, malls, EVEN OTHER FACTORIES, etc. After all, they're all just BUILDINGS, right? Why not abstract it out and have some general purpose "Structure Factory?" Instead of making sheds, we could make ANY BUILDING WE WANT. WHOOPEE!!

And let's not make it closed: let's expose OTHER METHODS for people to use this tool to fabricate types of buildings we've never even imagined; we'll allow someone to introduce THEIR OWN MODELS into the factory and produce entirely new buildings without us having to do anything! Brilliant!!!1

So, after the client requested something that would take any normal person half an hour at most, the AA manages to provide complexity, abstraction, some massive hairball of code (presumably vomiting OOP like it's 1994 and we all collectively forgot about the pitfalls of using a hammer to pound screws), well past schedule, etc., all of the AA's coworkers decided to kill him and hide his body in the woods.

Someone went out, spent twenty bucks and two hours of time to paint the shed blue, and everyone was happy.

Alastair -
Exactly. I want our people exerting maximum effort on the project at hand. They are paid a boatload of money. I expect nothing less than very good code.

- Lepto

--- There are many software systems where the software engineers do not know the problem domain they are "coding", so they cannot "sit down and code". For example, implement a control system for an automatic transmission to be embeeded in an automobile's computer. We better talk before we start typing. ---

Bill,

I somewhat agree. But there's a not-so-fine line between "We better talk before we start typing" and "It's been nine months, and we're STILL talking...".

And a lot of times, I think the obstacle _is_ the Architecture Astronaut; the programmer who is utterly obsessed with the details, wants to use the latest buzzword w/r/t software development and apply it to every facet of the project, adds new functionality in an almost whimsical manner, is prone to crafting concepts nobody else fully understands and don't really contribute to the bottom line, etc. Combine that with the fact that most Architecture Astronauts are people who don't fear technical jargon and are often painfully detail oriented, mix with three parts business suit and two parts marketing doink, and you have a recipe for total and complete disaster.

When projects with really complicated requirements are combined with people who are incapable of breaking down gigantic problems into manageable ones (and let's be honest with ourselves: as programmers, a lot of us absolutely blow at this; I know this because I've had a front-row seat for about a year now), and you end up with complete and utter paralysis. Every meeting degrades into this high-picture overview of a monolithic system that is like staring at the sun.

I know this because it is my current life, and I work on a project that is incredibly complicated, and our biggest obstacle is these AA types. I'm literally watching a train crash in fantastically slow motion. If the world rewarded UML, architecture proposals and requirements documents, we'd be filthy stinking rich. But that's not how things work.

Amen to that Jeff...seems like the comments have become a bikeshed discussion though! ;-)

With regards to your comment about "developers who are more interested in discussion than writing code." I find it interesting when I look at the SO site and see how many reputation points are awarded to people who ask questions like "What is your favorite developer comic strip?"

This comment is probably the most insipid one in the thread, but the cover of the book looks really cool.

Zach, you obviously haven't read all the comments

The single most significant information technology project in history, gauged by the number of people reached and the economic benefit to them, is GSM. And if you don't like meetings, GSM ain't for you:-) Seriously, it took massive architecture and standardisation efforts, roaming and interworking conferences, radio spectrum committees, a lot of government involvement by a lot of different governments...oh yes, and a bit of code too...

Good Topic. This holds so ture for discussion forums as well. I have found that the people who don't partake in the "Chit/Chat" sections of programming forums tend to be the most helpful with regards to writing questions.

Although allow me to make the point that this is why I do not like open source. Allowing anyone to help out is like having a programming house with a revolving door. At the end of the day any project should have a vetting of all participants as this is the only way to avoid such issues

"The bikeshed effect is not about abstractions, but about trivialities. An architectural astronaut would not be debating the shedís color; heíd be trying to come up with a scheme that would allow the shed to be any color the client wanted."

This neatly encapsulates the silliness of "Architecture Astronauting".
6 months of arguing whether you can handle spots and stripes at the same time, and you'll be beaten someone who just kept selling blue sheds. And then offered their customers some red paint.

Jeff,

No.

You totally take the focus off of how to pitch a great idea and simultaneously squash the bikeshed project's consumed time.

So how do you push a good idea through?

DESCRIBE THE PROBLEM, THEN STATE YOUR CONTRIBUTIONS. Have a bulleted list of contributions. Do not make anyone guess what your contributions are, and show how well your contributions solve the problem.

Rather than diving in coding, practice getting ideas through FAST. The best way to practice this is EXPERIMENTATION AND PROTOTYPING. Challenge yourself with an idea, no matter how silly. A mini-research problem. Write down the problem, and how you plan to solve it.

Experimentation and Prototyping, followed up by practicing your elevator pitch, is the only way to train yourself to become really good at blowing past the foot draggers and empire builders.

And practice your elevator pitch at the water cooler, to one person at a time, until at least three people are on board with you. Then when you pitch it at a meeting, you hopefully already have a silent majority. Then you just have to squash the minority who want to talk about bikesheds.

Anonymous Coward,

Most IT people don't see the consequences of their actions. They are too far removed from them to literally even see them. Accordingly, they don't realize they're emphasizing small differences.

My approach is ad hoc, but there's a general pattern I seem to follow: First, flatly assume that the programmer has backed himself into a false dilemma. Then rephrase the false dilemma as a paradox or set the problem in a different context that highlights the logical fallacy (such as a false dichotomy).

Paradoxes work well, because studies show almost all errors are errors of perception, not logic.

Tom,

No. The background of the bikeshed story is that it is a marginal line item delaying the construction of a complicated nuclear power plant.

Bikesheds are like spell checkers. These days, they get thrown into other office automation programs and nobody sells a spellchecker. You don't have competition selling blue bike sheds. You have competition adding more features than a bikeshed to a nuclear power plant. Competition adding more features than a spellchecker to a word processor, such as mail merge.

nice post............

ìNo. The background of the bikeshed story is that it is a marginal line item delaying the construction of a complicated nuclear power plant.î

Just to continue the bikeshed nature of this discussion further, I donít think this is quite right either. As I understand it the original point of the bkeshed effect, was that easier to get a nuclear plant built than a shed. Because the idea of a shed is trivial everyone feels then can contribute to the discussion, and has to in order to look like they are doing their job. Whereas with the plant, no one understands it so they just rubberstamp the proposal so as not to look stupid.

exactly right Steve W

Given the general surrounds of the pictured bike shed, and assuming that this continues around to the other 2 corners, one would have to wonder what kind of developer would prioritize a discussion on bike shed painting, when clearly the most significant concern would be its apparently useless location.

Considering you clearly need at least a bike to get to and from the bike shed, what purpose does it serve?

If your answer is that it serves the purpose of storing bikes for people that wish to drive long distances, on very rough roads, to get to locations in the middle of nowhere, just so they can peddle through prickles and dirt, and likely spend all day repairing one puncture after another... then I'd have to ask....is that a Linux users bike shed by any chance?

Why a book that talks about open-source costs 16 Ä? I call it irony :P

Why do we think that not doing something "useful" for some time out of the day is bad? Having a little fun in discussions about aspects of the design is not invaluable just because it doesn't add value to the project. I like software design but it's not the end all be all of life. In discussions like this I sometimes feel like we are trying to prostrate ourselves out before the almighty project at the expense of our humanity. I think that this point of view is the problem more than the "wasted time" itself. Let's not stress ourselves out over the little things.

really good to know about this. so coo.