Re^2: Musings: Why do well-intentioned projects go so wrong, so often?

I don't think that's what sundialsvc4 meant. I think he was talking about "knowing the audience" and knowing the range of the project. You do not need to know how exactly will everything look or work, but you need to know what's the purpose and range. And not try to be everything to everyone. But maybe that's what I would like him to think by that :-)

Jenda
Support Denmark!
Defend the free world!

Comment on Re^2: Musings: Why do well-intentioned projects go so wrong, so often?

Replies are listed 'Best First'.
Re^3: Musings: Why do well-intentioned projects go so wrong, so often? by locked_user sundialsvc4 (Abbot) on Dec 05, 2007 at 19:46 UTC
You got it right. The question of “what does it do” is much more important than “how does it mechanically go about doing it.” Most machinery has a protective cover; so does programming. It is a surprisingly easy thing to buy-or-build a beautiful looking machine that does exactly what its designers intended, but that doesn't do what you need it to do. You get the very-uncomfortable feeling, uncomfortable and also very-correct, that the design team never really understood what was needed. So the machine is tight, beautiful, well-made, and utterly useless. Another issue can be the unspoken requirements. For example, no matter what my inward- or outward-facing website is supposed to do, I don't want it to be shame-faced by some `"133t h4x0r d00d,"` and I also don't want it to wind up on The Great Grand-Nephew of Web Pages That Suck. I want it to be, as IBM would say, “Reliable, Availabile, Serviceable.” To have “merchantability and fitness to a particular purpose.” That takes a tremendous amount of discipline to achieve as a consistently reliable and predictable process, and most shops don't seem to be able to do it.

Replies are listed 'Best First'.

Re^3: Musings: Why do well-intentioned projects go so wrong, so often?
by locked_user sundialsvc4 (Abbot) on Dec 05, 2007 at 19:46 UTC

You got it right.

The question of “what does it do” is much more important than “how does it mechanically go about doing it.” Most machinery has a protective cover; so does programming. It is a surprisingly easy thing to buy-or-build a beautiful looking machine that does exactly what its designers intended, but that doesn't do what you need it to do. You get the very-uncomfortable feeling, uncomfortable and also very-correct, that the design team never really understood what was needed. So the machine is tight, beautiful, well-made, and utterly useless.

Another issue can be the unspoken requirements. For example, no matter what my inward- or outward-facing website is supposed to do, I don't want it to be shame-faced by some "133t h4x0r d00d," and I also don't want it to wind up on The Great Grand-Nephew of Web Pages That Suck. I want it to be, as IBM would say, “Reliable, Availabile, Serviceable.” To have “merchantability and fitness to a particular purpose.” That takes a tremendous amount of discipline to achieve as a consistently reliable and predictable process, and most shops don't seem to be able to do it.