*laughs* I don't believe in them. I am merely stating that for us to be truly successful, "solid, unshifting requirements" go a long long way. In fact, I'd say that if I had solid, unshifting requirements and not much else, I'd do better than I would without them, but with everything else. Would you disagree?

------
We are the carpenters and bricklayers of the Information Age.

Then there are Damian modules.... *sigh* ... that's not about being less-lazy -- that's about being on some really good drugs -- you know, there is no spoon. - flyingmoose

I shouldn't have to say this, but any code, unless otherwise stated, is untested

If someone handed you truly solid, unambiguous requirements, that cover all cases then you've been handed your final program, only written in the wrong language. If anyone could guarantee a source of requirements like that, then we could just write a good compiler and get rid of the programmer.

Shifting and ambiguous requirements are not just an annoying part of your job, they are why you have a job.

This is a straw man. Requirements are the "what". Design is the "how". If I was handed a complete design, of course a compiler could translate that into a program a computer could understand. But, translating requirements into an appopriate design is the job of the programmer, at least in my experience. The actual typing is a side effect of the job.

I look at it as an artform. Some people work in paint or food. I work in programming languages. The requirements could be "I want a picture of the Pieta." The design is the artistic layout - "The Virgin is on the left, the Christ-child on the right." The compiler is "Sculpt it in marble" or "Sculpt it in papaya". :-)

------
We are the carpenters and bricklayers of the Information Age.

Then there are Damian modules.... *sigh* ... that's not about being less-lazy -- that's about being on some really good drugs -- you know, there is no spoon. - flyingmoose

I shouldn't have to say this, but any code, unless otherwise stated, is untested

I'd say that if I had solid, unshifting requirements and not much else, I'd do better than I would without them, but with everything else. Would you disagree?

No, I wouldn't disagree.

If I had a little man that could spin straw into gold I'd have much less trouble paying the rent each month. Would you disagree? :-)

In my opinion fixed requirements are one of those harmful lies we tell ourselves. It encourages us to focus on the impossible (fixing the requirements in stone), blame the wrong people (it would of worked if the client hadn't changed things) and prevents us addressing the real problem (finding a process that can deal with the reality of changing requirements).