S3M - Software Maintenance Maturity Model

Monday, June 30, 2008

The un-maintainable system

I am in california all week long. We are looking at an un-maintainable system in the stock exchange business domain here. The story goes like this. The system has been developed in the nineties and has been changed daily over time. Its now in a position that they cannot easily touch it without creating side effects. With staff turnaround the key developers and maintainers have moved on and this is starting to create a lot of problems for management. They would like to know if this system can be salvaged or move on. I'm in the system salvaging business ! I'll try my best first.

What to do ? I guess you've all been there so here is the way out.First we've run gather the team and asked what they think can be done, over a period of three months, to unlock this issue. I'm not here for long so I cannot afford to create a dependency on my knowledge/tools, here's what came out:

- Get a task force going to find who knows the environment/systems and dependencies
- Identify the low bearing fruits (what can be fixed first: by humans and by toolset)
- Decide on key areas re-structure/re-engineering
- Make a maintenance plan for this system

I decided to attack the automated assessment of the 'beast' and give them a picture of where complexity and dependency is located. So today i've looked at all the change tickets of this year to map where change has been mostly happening this year. I also made a test run of the source code in our toolset to calibrate the measures. Tomorrow i'll tell you more about it.