Software maintenance is unavoidable and a dreaded type of work. Almost 50% of IT department’s time is spent on software maintenance tasks: it is one of the major headaches of the CIOs and one of the least favorite topics of all executives.
It is easier to ignore software maintenance altogether; ah, why fix it if it is not broken? As the pressure on the IT department increases with the business requirements, the challenges, the evolving problems, software maintenance tasks receive less attention. To be frank, sometimes they even deem “pointless.” First hand experience.
There is a pain point of course: the IT budget stays flat, business requirements increase and nearly half of the staff is employed on the maintenance work, making projects take hits and the additional projects flow in.
There are three major factors that make continuous software maintenance necessary:
- Infrastructure changes: If your code is running on – say – a Windows Server 2000 and you change your infrastructure to Windows Server 2012 R2, you need to analyze and update your code as necessary.
- Spaghetti code: The code is unstructured, uncommented, undocumented, the coders are long gone/retired, it is impossible to untangle the code but it runs mission-critical systems.
- Quirky code: With the pressure from the business side, the code is not thoroughly tested but deployed to production systems. It works, but with some quirks. When these quirks become overwhelming (and accumulate over time), the maintenance team steps in to fix.
There is nothing CIOs can do to avoid all these reasons but there are some steps that they can take to reduce the time spent on the maintenance tasks.
In this cloud age, the first thing to do is to consider using the cloud versions (or equivalents) of the in-house systems. There are of course reasons why businesses are migrating to SaaS offerings like Office 365 with Dynamics CRM, Salesforce.com, Google Apps etc.. First, with the SaaS offerings the software maintenance work falls on the cloud provider. Second, these offerings have defined service levels, so there is a guaranteed uptime. Third, the offerings provide ubiquitous access. So the migration looks like hitting three birds with one stone.
Next thing is to evaluate generic offerings against the custom applications. Users often get customization wrong and want to application work exactly as they want, rather than understanding how a particular task can be accomplished with the application. If the application looks a bit different, users tend to reject it, often just because they do not want to change their habits. But if proper communication is established and support is received from both management and the users there is just one reason that this migration cannot be made: if the custom providers are providing a real competitive advantage with their applications. If not, you can just go ahead and try to evaluate options.
If these two actions cannot be taken, then it would be wise to invest in test bench software. Test bench software test more than one area: you can test the quality of the code, stress test, underlying database activity, data footprints etc.. With such an assistance from an application, you can pretty much increase the quality of the application and in turn reduce the time that is needed to fix it.
And finally, you can rearrange the personnel. If some of your people are more talented in development and some of them in testing and maintenance, you can pretty much shuffle the responsibilities. You can then provide training for the testers and the maintainers. Your budget may not allow for such an additional training but you need to stand for it to justify and adopt such changes.
What are your solutions to reduce software maintenance? Hit the comments below!
Image credit: imtsbenin.com
