7 Ways to Improve Software Maintenance

Here are some approaches and steps organizations can take to perform software maintenance while creating as much time as possible for new software development.

In 2019, Tidelift, an Opensource support and maintenance organization, conducted a survey of software developers that revealed that developers spent less than one third of their time (32%) developing new code. In the same survey, developers said that 35% of their time was spent on software maintenance.

My own experience in consulting with companies is that the amount of time spent on software maintenance is closer to 50%.

In either case, the time spent on maintaining software prevents organizations from pursuing new projects and getting things done.

At the same time, maintaining the software that you have created or inherited is a fact of life.

Software maintenance is defined as “a part of Software Development Life Cycle. Its main purpose is to modify and update software application(s) after delivery to correct faults and to improve performance. Software is a model of the real world. When the real-world changes, the software requires alteration wherever possible.”

Given this, what steps can organizations take to perform software maintenance while creating as much time as possible for new software development?

1. Listen to your help desk

No function in IT has a better finger on the pulse of application performance than the help desk. The help desk gets all of the questions and problems from users. The people who work the help desk know from the calls they get which applications are most problematic, and why. If more IT organizations patched help desk insights into their application development brainstorming and performance evaluations, they would be more successful identifying areas of persistent application problems and failures so these areas could either be addressed fully by repairing them or retired and replaced with another solution. Just as importantly, the knowledge gained from application trouble “hot spots” at the help desk can be learned from so the same mistakes aren’t repeated in new software development.

2. Engage QA

In too many organizations, developers up against tight deadlines tend to throw their work “over the wall” to QA at the last minute. Then, only partial application testing gets done before the app gets deployed into production. When the app goes live, there can be weeks of problem reports and troubleshooting, with fixes and workarounds resulting. Conversely, by thoroughly testing applications upfront for technical correctness, integration and usability, post-production software maintenance can be drastically reduced. To facilitate this, project managers need to plug in and ensure adequate times for software QA.

3. Consider a move to the cloud

Organizations using broken on-premises legacy software can consider making a break from endless maintenance by moving to a cloud-based version of the software that is offered and supported by the vendor. In a scenario like this, software maintenance is moved out of the shop and into the hands of the vendor. One disadvantage is that you never can be sure when the fixes or enhancements you want are going to get done — but the move could well be worth it if you can live with the inconvenience.

4. Sunset the applications that aren’t returning value

Almost every organization has a legacy system that no longer delivers the value it once did. This is a time to consider sunsetting that system and potentially planning a “rip and replace” with a new system. Rip and replace works when there are few needs to integrate the system with other software that is running. In cases where rip and replace is viable, you can shift much of your system maintenance for the new system to the supporting vendor.

5. Always regression test

The impulse when you’re under the gun to finish a project is to meet deadline and skip some of the quality tests. One critical test is the regression test, which places any application that is newly modified in a simulated production environment with other applications to test and ensure that integration with these other applications and called routines is working properly. When regression testing is skipped, risk heightens that a newly modified app will break or cause other pieces of systems to break because of a coding error that was introduced. This brings down systems and causes service outages..[…] Read more »…..

 

Share