in reply to Musings: Why do well-intentioned projects go so wrong, so often?

Take the time to define “what does it do, and for whom does it do it?”

I hope you don't mean the hoary old "Plan me harder!" chestnut. isotope and I discussed this the other night, and neither of us can think of a project where completely nailing down requirements before writing code actually made a project succeed.

Contrarily, we could both think of plenty of projects that almost released on schedule and very nearly came in on budget but never satisfied the users despite stubbornly sticking to the jot and tittle of the original specification. That's okay, though, because next time they'll plan harder!

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

Replies are listed 'Best First'.
Re^2: Musings: Why do well-intentioned projects go so wrong, so often?
by KurtSchwind (Chaplain) on Dec 04, 2007 at 16:19 UTC

    I'm with you on this one. My corp is always saying that we need a complete set of requirements to start the work.

    I couldn't disagree more. As soon as you have enough requirements, you should start and then start iterating through solutions. What's "enough"? I'd leave that up to the lead developer.

    --
    I used to drive a Heisenbergmobile, but every time I looked at the speedometer, I got lost.
[reply]
      My corp is always saying that we need a complete set of requirements to start the work.

      If you had a complete set of requirements in detail sufficient to describe the problem to solve in its entirety, you would already have the complete source code to the software.

[reply]
Re^2: Musings: Why do well-intentioned projects go so wrong, so often?
by Jenda (Abbot) on Dec 04, 2007 at 23:03 UTC

    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!

[reply]

      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.

In Section Meditations