Start Stretching Early

Spent some time on plane today and while catching up on my reading I came across the following in a community posting:

Most evidence I’ve seen indicates that 30-40% of the resources on a project not in its early phases using MOST methodologies should be dedicated to rework – something most customers could not swallow if said literally.
This of course is a broad statement.  Factors that seem to affect this (the variables):
1) Flexibility of the architecture – can increase maintenance costs and developer learning curve, but rework can be minimized.  Might be a tradeoff worth considering depending on customer perceptions and requirements.
2) Elegance of architecture – If the architect can foresee changes and design for them, then rework is easier…but this requires a combination of experience and a crystal ball – by no means predictable and can only be measured successfully after the fact.
3) Cross-area development – if developers are constantly switching areas of the project where they are working, this increases the likelihood that they will do something in one area that is not as anticipatory of future changes and perhaps not as elegant as someone that knows the area better.  The tradeoff here is that you reduce the risk exposure to someone leaving, because there is likely someone else ready to step in.
4) Requirement Variability – duh
5) Early Requirement Finalization – duh, but does this ever happen?

The most insightful part of the post was the very first sentence.  The rest of it, was a reasonably insightful explanation of why this conclusion makes sense.  However, I find it refreshing to see someone address this issue so rationally and direct.  Usually, I find myself in the minority on this front.  In this case, it was an accomplished architect in response to a generic question about rework brought on my Agile-type methodologies.

In reality, most of the methodologies that are being pawned off as new are just re-organizations of old schools of thought.  The practices are given new names, sometimes combined for different purposes, but they exist in the same world.  They are subject to the same laws of science and the same volatility of humanity that every other methodology has been subjected to for quite some time.

If you have a reliable architect, following something resembling a clear vision, you will arrive at a destination using a methodology.  If the thing being built is poorly defined or inflexible, if the user volatility is not kept in check, then you will have rework.  Change is just the reality of working at the speed any business runs at these days.

Now that you know that change is emminent, you can fix your mind to adaptability, instead of clutching so tightly to any semblence of stability that happens by.  You are going to have to be flexible, and rewrite something as the vision evolves.  My advice is that it's best to get on with it then, eh?