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. ;-)