The Agile Executive

A reader of the post Make the Hairs on the Back of Your Neck Stand Up posed the following question:

I wonder if there’s something inherently un-Agile (and thus, unable to change fast enough to meet new business demands) about older enterprise software, or just ERP software?

The answer IMHO is size. To quote Capers Jones:

Since defect potentials tend to rise with the overall size of the application, and since defect removal efficiency levels tend to decline with the overall size of the application, the overall volume of latent defects delivered with the application rises with size. This explains why super-large applications in the range of 100,000 function points, such as Microsoft Windows and many enterprise resource planning (ERP) applications may require years to reach a point of relative stability. These large systems are delivered with thousands of latent bugs or defects. 

The phenomenon described by Jones is often exacerbated through the “ship more infrequently” syndrome. IMVU’s Timothy Fritz describes it as follows:

While this may decrease downtime (things break and you roll back), the cost on development time from work and rework will be large, and mistakes will continue to slip through. The natural tendency will be to ship even more infrequently, until you aren’t shipping at all. Then you’ve gone and forced yourself into a total rewrite. Which will also be doomed.  

You might choose to reduce your technical debt instead of trying total rewrite. Chances are you will struggle to find Elbow Room for Handling Technical Debt. My hunch is that once >50% of development resources are assigned to maintaining the software on an on-going basis, it is time to get into refactoring big time. If you don’t, sooner or later you are likely to find you can’t afford the software you developed.