I don't fully buy the no-rewrite rule, myself.

I actually subscribe to the opposite theory: plan to write two - the first one is just throw-away. If I could just stop all requirements from coming in for a month, I would be able to finish the other half of my rewrite of our entire perl infrastructure on our team. The first design had holes in it large enough to drive a truck through. The new design answers all the problems of the old design, plus plugs the holes. But it requires a significant rearchitecture.

As far as the programmer before me encountering problems that aren't readily apparanet... doubtful. That previous programmer was me ;-)

This is a massive effort to move from shell scripts that had everything hardcoded in wierd places, ... to perl code that was completely data-oriented. I worked on the shell scripts for a few years before we started the move to perl, so I'm intimately aware of the pluses and minuses of the original code. I designed the first perl infrastructure, handling all the pluses and solving all the minuses of the old shell code. Yes, all of them. But, reality has a way of side-swiping you. In the design, I only took care of all the immediate issues, without looking to future issues. Only by putting it to some use (we delivered two major releases of our off-the-shelf business software based on the original infrastructure) have we figured out what needs to be kept, what needs to be rewritten, and what simply needs to be discarded. Most of what needs to be kept is concepts, not code.

That's just the way I look at it. But I didn't suggest rewriting ('porting') the shell code into perl to management until I did understand the subtle issues in the problem domain. So maybe this is just an opinion given different assumptions... and not an outright disagreement.

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.

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