Re^3: Structural Elegance

If I could just stop all requirements from coming in for a month . . .

But this is exactly the problem XP looks to solve. People doing Waterfall development often say "if we could just get the customers to solidify their requirements . . . ". XP people, OTOH, say that practical experiance shows that customers never solidify their requirements, so let's figure out ways to deal with it.

In general, I can't come up with many good reasons against XP (though there are plenty of ignorant critisim writen against it). Rather, there is just something that doesn't seem quite right about it.

"There is no shame in being self-taught, only in not trying to learn in the first place." -- Atrus, Myst: The Book of D'ni.

Comment on Re^3: Structural Elegance

Replies are listed 'Best First'.
Re^4: Structural Elegance by Tanktalus (Canon) on Apr 21, 2005 at 14:12 UTC
Actually, solidifying requirements isn't a problem. In fact, dealing with unsolidifiable (:-}) requirements is exactly what the rewrite is for. The original perl design I'm referring to took a sum total of where everything was sitting at that instant in time. It dealt with all known requirements pretty well (I'd give it an "A" if I were marking it for completeness - not an "A+", though, as there were still problems). The problem is that it didn't deal with unknown requirements very well. Having gained about 2 years of experience using the original design, I have a better grip on where unknown requirements can hit us. We, in turn, rely on other tools. We must understand the limitations of those tools and need no more flexibility than they give us. But we should not introduce other limitations artificially, because that artificially limits our ability to handle these ever-changing requirements. Flexibility was an unknown requirement. I'm sure even that can be changed ;-) I need that month for everyone to back off just to finish the rewrite. The requirements can pour in after the month, I'm reasonablly certain that we could handle them at that time with the new and improved flexibility, and still hit our dates. But as long as those requirements are there and known, my manager isn't likely to be happy about me going and rewriting the core logic to our infrastructure. ;-)	[reply]

Replies are listed 'Best First'.

Re^4: Structural Elegance
by Tanktalus (Canon) on Apr 21, 2005 at 14:12 UTC

Actually, solidifying requirements isn't a problem. In fact, dealing with unsolidifiable (:-}) requirements is exactly what the rewrite is for. The original perl design I'm referring to took a sum total of where everything was sitting at that instant in time. It dealt with all known requirements pretty well (I'd give it an "A" if I were marking it for completeness - not an "A+", though, as there were still problems). The problem is that it didn't deal with unknown requirements very well. Having gained about 2 years of experience using the original design, I have a better grip on where unknown requirements can hit us.

We, in turn, rely on other tools. We must understand the limitations of those tools and need no more flexibility than they give us. But we should not introduce other limitations artificially, because that artificially limits our ability to handle these ever-changing requirements. Flexibility was an unknown requirement. I'm sure even that can be changed ;-)

I need that month for everyone to back off just to finish the rewrite. The requirements can pour in after the month, I'm reasonablly certain that we could handle them at that time with the new and improved flexibility, and still hit our dates. But as long as those requirements are there and known, my manager isn't likely to be happy about me going and rewriting the core logic to our infrastructure. ;-)

[reply]