The book Producing Open Source Software: How to Run a Successful Free Software Project is a fantastic reference for anyone involved in a software project -- whether you're running the show or not.
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.
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?
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.
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.
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.
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.