@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.
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
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.
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’
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.
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.
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:
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.
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.
