S3M - Software Maintenance Maturity Model

Friday, August 1, 2008

Salvage is the final decision

Using Dr Koskinen approach to decision making can help support this business case.

1) Continue to use/maintain the current software by modernizing it (baby steps first)
2) Replacement a) try to find a solution ou there
b) complete rewrite of the system

Rewrite is estimated à 160,000 hours of effort. After discussions the decision is to salvage the existing system. Strategy will be to migrate to newer technology and refactor worst parts. Scalability is also an issue. I propose to go with 'cloud computing' backend. Looking at the system there are currently enough information to pass from C+ to C#. A small pilot done this week shows that the effort will be around 6,500 hours to convert. Only 8% of the system requires refactoring. This will take 3,000 hours to do and includes the migration of the obsolete Borland database to a more recent (and scalable) technology can easily be achieved.

Parallel run is mandatory so existing Dabatase + stubs will be used in parallel with new database. I'm out of there and preparing the new software maintenance course at the University starting in September.

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.

Monday, May 26, 2008

Maintenance and Agile: SCRUM, Xtreme, DSDM

Maintenance is agile. No need to say more ! Maintenance personnel probably invented Agile and never used the term! 

Scrum, Xtreme and DSDM practices can be applied without much modification:

1. Daily meetings
2. Quick iterations
3. Impact assesssment, customer contact to validate change/defect
4. TRAC (or similar toolset) displaying In progress, 
completed, reopened, closed tickets and other information
5. Usage of Wiki for collaborating with others
6. Requirement workshop for complex changes/defects
7. Review and Retrospective

Maintenance has a small iteration length. For projects, plan a  "maintenance slots" in an iteration/span>

Monday, May 19, 2008

Maintenance

Here is an added list of secrets:

  • New Secret #1 - Stop the bleeding first. Implement a Standard Operating Environment standard that restricts the introduction of too many new technologies and identifies the one that are going out. This will promote the use of some and discourage some other. 
  • New Secret #2 - If old harware makes it to the museum should'nt it be time to stop running old software in production and move it to the museum?
  • New Secret #3 - Stop pushing garbage into production. Its time to put a formal transition process in place. If its not finished its not ready to be maintained.
  • New Secret #4 - Hire people in maintenance first. Anyone who has not maintained a software cannot understand how to develop one. Its a simple affair and you have to walk in those shoes first or else you cannot understand how to develop maintainable code.
  • New Secret #5 - All development projects must deliver a test system on a test platform. Enough of delivering only code and documentation. Give us your test system and all the test cases and tools. If you did not build this how the hell did you test that software?
  • New Secret #6 - The software project must give us the defect list and the SLA terms before the transition can be completed. If they developed a software without any SLA terms it means that there are no formal quality characteristics in that software. We need to know that before we take over the responsibility for this software.
  • Secret #7 - Cleanup the process so that it helps out instead of slowing down everyone. Maintenance is already 'agile'. As a friend said recently 'with everyone using agile now it all looks like maintenance to me!'. Consider having separate maintenance groups as it raises awareness of quality issues at delivery time and beforehand.
  • Secret #8 - Get on with measuring the productivity and use www.isbsg.org database to compare. This is a wise decision before your boss decides to ask you for the numbers because he thinks of Offshoring.





Secrets of Software Maintenance

I remember this post by David EddyPublished: July 1, 2000 in TDAN.com July 2000. In my next post I will try to update this list with some new hints  !
  • Secret #1 - There are no secrets. If you can accept this reality, you are well on your way to understanding the true "secrets."
  • Secret #2 - Maintenance is an inherently bottom-up process, primarily because maintenance is a game of details, and managers are not hired to "do" details.
  • Secret #3 - Good maintenance, like good development, is just the consistent application of sound life-cycle practices (requirement analysis, configuration control, independent verification and validation, et al.) that have been well known and understood, if spottily applied, for decades.
  • Secret #4 - Development and maintenance are merely two sides of the same coin. To believe that one is better or worse than the other entirely misses the point. They are a continuum very much like the mathematical oddities of a Möbius strip or a Klein bottle.
  • Secret #5 - The administrative infrastructure that supports the development/maintenance effort must become self-sustaining. Otherwise, the effort will be seen as busywork (read "costly, paper-pushing bureaucratic waste of time"); and it will die as soon as the original sponsors shift their focus or, worse, mutate to take on an expensive life of its own that is unrelated to productive work.
  • Secret #6 - The job of management is to put into place the practices which enable the work of fixing, extending, and enhancing systems that support the business. 
  • Secret #7 - Organizations that are more intent on affixing blame for software problems than on ensuring that the conditions which caused the problem are removed/resolved will always regard maintenance as a headache to be endured until the mythical silver bullet is found.
  • Secret #8 - There are no spectacular winning-touchdown-in-the-last-3-seconds events in this game and certainly no silver bullets. Success is simply the steady, incremental application of the basics one small tactical step at a time.

Tuesday, May 13, 2008

Hints and tips on solutions to maintenance problems

Here are common solutions that I apply:

Staff issues

1)The personnel does not understand the system - Training or send the staff to the user site to learn by looking at the others using it;

2) Management is too focused on development - Communicate better the importance of maintenance. Report regularly on maintenance activities. Use Dr. Abran's reporting approach where trending and internal benchmarking are the key representations. Also you can benchmark against ISBSG 'maintenance dabatase' to show you are doing well !

3) Maintenance personnel is down - Retention bonuses, mix the teams, rotate staff send some to operations/development for a while, update their toys (equipment, phones, ..), give $ or a restaurant/cinema voucher when a challenging change in prod is defect free, implicate them in R&D, SLA's, Contract, DRP or Transition (only if it is perceived as fun :). 

Time problems

4) System changes constantly - Group requests in packs and do a certain number of versions per year.

5) Changes are piling up - Ask the CCB to prioritize them...what you have no CCB well establish one... what you do not know what a CCB is...a Change Control Board where user representatives are forced to 'inner fighting' to set your priorities...I like to see then go at it !

6) Night changes blast the online production - Do a small reengineering project to free up some batch schedule time. Squeeze that request in your work schedule.

Technical problem

7) Production system is hard to maintain - Start on the 'rejuvenation journey'. Each small change must trigger a small internal improvement. This works for systems that we often change and that are there to stay. Else look at Dr. Koskinen arguments to convince management that its time to invest a bit if you want to reduce maintenance costs.

8) Production system is hard to test - Well two elements to this one: long term would be to force development (or suppliers) to give you a testing system with the new systems they transition to you. For the existing, install a test system..if its not already there..and each time you touch it you spend a bit of time developing the test tools surrounding it.

The need to compromise 

9) Maintenance is done only in panic mode and compromises the production - Slow down...or manage up...you'r gona bust...or production will bust you... Allow more time to QA and look closely at what the night fix have done.

10) Maintenance personnel does not have enough tjink time to fix problems - Assign seniors to juniors to coach them before they proceed too far.

Maintenance costs problems

11) Costs are going up - Establish different costs by maintenance categories. Customers love enhancements and hate defects. Raise costs in enhancements and lower costs in other maintenance categories. Outsource/Offshore parts of the 'low interest' work to show you care. You better think about it yourself before someone thinks about it for you. Its time to make a business case to convert the system to a more recent language or platform.


Evolution all the time - an opportunity to improve it

Code evolves constantly during the initial development. When you look at the TRAC project (trac.edgewall.org)  you can see all the tickets raised during the development stage of a project. Soon I will be posting a software maintenance version of TRAC that we are developing currently. I will place it in the S3M WIKI so you can take it and try it. We also have developed a script to install TRAC easily. I will place it there too ! Lets get back to our topic. 

When you open up the code to make a change you have an opportunity to make a small improvement. I like this approach instead of creating a reengineering project. What to look for:

- A loop that is too long or too deep.
- A class that has no cohesion
- An interface that does not give a coherent abstraction level
- Too many parameters
- Classes that do not do anything meaningful

Steve McConnell's book 'Code complete' tells you some more 

Friday, May 2, 2008

Deciding where maintenance goes

We always have a debate on where software maintenance should be done. Is it better in a separate group or the developer maintains the software he builds for the rest of his life! Our second survey results look quite the same as the first one:

Cust. Sat: How do end-users feel when served by this group. Costs seem higher or lower with this model? Is it longer to be served by this group? How about the quality of the software over time.

Arguments Against                                 Arguments for
Separate Maintenance                            Separate Maintenance

Cust. Sat: Users like the initial developers      Initially less happy 
Costs:   Seem to cost less                            Seem to cost more
Delays:     Slow and impacts other projects      Perceived as Quicker
Quality:   Mostly in the developers head              Tend to be higher here
Size:          Good model for small shops            Better fit in big organizations


Monday, April 21, 2008

Opening up the blog this morning

Welcome to the software maintenance blog. 

We just got the website going today and I am feeling my way around to see all the features. 

Friday I had to buy a copy of my last book 'Software Maintenance Management'. The editor did not tell me it was out and did not sent a copy beforehand. Times are tough !

This week I will start up the Wiki and the Blog with the first Articles and will continue to fill up the site with content. Feel free to send me comments for improvements.

I also have a meeting to help a friend who has an ERP firm to plan the reengineering of his product out of Borland C++ to C#. I will meet up with a Ph.d. student we met at CSMR to see what can be planned for the summer.