Four key components for best practise software maintenance

 

In this article I will discuss 4 key components for effective software maintenance.

Change is inevitable, it’s happening all around us, all the time. If the world is changing so to is your business, and if your business is changing, don’t your processes and software need to as well? I’m not just referring to profit increasing innovation or upgrades to stay in touch with your competitors. I’m talking about upgrades and fixes to your applications due to organic changes to your business and industry. The need to effectively and sustainably maintain software is obviously paramount then. Let’s discuss some key points that need to be understood in order to grasp the importance of software maintenance. 

 

In this article I won’t be referring to small scale applications, websites or apps. These are often pretty easy to update and change. On the other hand, for complex enterprise systems, you are looking at hundreds of people over months to release one small change effectively so it doesn’t interrupt other services. I will assume you either work in an organisation that has a IT Service Delivery model for software or you feel you need to start considering implementing a model. 

Let’s begin

Have you ever asked, how do we effectively maintain our software, while at the same time running and releasing new features, patches, bug fixes, upgrades etc? How does it all fit together in our day to day work and release cycles?

 

The answer is, that there is no one size fits all. There is of course best practices, ITIL for example. Here I will discuss what I think works well. This will be based on the average of the IT team setups I’ve been apart of. I’m not going to outline my version of a best practice, many smarter people have already spent their lives defining this and teaching it. I intend to outline a framework of thinking you should consider to help setup or improve your application maintenance life-cycle.

 

I see four key components to consider when assessing your software maintenance practises, these include:

1. Identify issues and keeping a backlog
2. Reviewing the issues that have been raised
3. Having a healthy release cycle
4. Testing your releases and seeking feedback

 

Component 1: Identify issues and keep a backlog

How do we even know there is an issue or a problem that needs fixing?

The source comes in two main ways:

• Known production problems. These could be issues that have been raised in the past or that were released into production, with the intent to fix in a future release.
• Testers, analysts, users or customers notify the product owner of the problem.

Component 2: Review process issues and backlog

How do we know its an issue? Just because someone says something is a problem, doesn’t mean it is. In complex systems, with complex business processes, the line between what should happen and what shouldn’t often comes down to opinion. Through in a lack of training and documentation, and you can have a pretty messy situation.

 

Best Practise

Ideally we should be able to identify an issue by asking the following question:

• Is the system doing what it was designed to do? This requires documentation of what it was supposed to do and/or expert knowledge from users or business teams. If it is not doing what is it supposed to do then an assessment has to be made. This is generally done by a Business Analyst, in consultation with a subject matter expert (SME). Having designated SME’s in your organisation can prove very useful. You must then ask:
  • Is the User using the system incorrectly?
    If so, this requires a focus on training or improvement in UX in the system.
  • If the system is not working as intended then this should be raised as an incident and requires a change to the system.
    

Having decision makes such as Business or Product owners, SME’s will go along way in making quality change decisions and speeding up the time it takes to make change.

 

Component 3: Have a release schedule

Now you have a backlog of issues, which issues do you spend your resources on? These are the factors you should be discussing within your team:

1. Return on Investment
2. Disruption to other teams or services
3. Quick wins
4. Long term gains

 

Best practise

The first thing you need to consider is your return on investment. How much will it cost verses what will the gains be. This is a simple concept, but one that is often overlooked, or at least not discussed as the main reason for giving higher ranking to certain software changes. You will also need to consider disruption to other services by performing the  change and if any other teams need to be involved. I like the idea of quick wins, because it helps the team feel like they are achieving something, if the majority of tasks take too long or fail. Long term gains are also important, an example of this could be a focusing on root cause, to ensure reoccurring issues do not arise. Especially if all the small issue accumulate to the consumption of a lot of resources (time and/or money).

 

Component 4: Testing your release and seek feedback

Of course, we know we need to test before and after we release. However, one form of testing that is often overlooked, but should be incorporated is seeking feedback. The normal train of thought, is once the change has been release, if no one complains then it works. A good doctor will call a patient sometime after their treatment. Talk to the end user and the business owner, see what they have to say.

 

In summary