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.
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.
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
ì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.
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 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.
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.
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!
