The Software Maintenance Quotient

Image by chrisreadingfoto

Everyone loves the delivery of new software features. Users appreciate the added value. Developers thrive on building new things. Companies want to strengthen market position, earn more users, and charge more.

While not as glamorous, maintaining software is just as important. When maintenance is ignored, adding more features becomes more and more difficult until forward progress grinds to a halt. Companies that consistently move their software forward are just as good at managing maintenance as they are at managing the development of new features.

Every company has a “Maintenance Quotient” that represents their effectiveness in performing maintenance on their software:

\[ \text{maintenance quotient} = {(\text{developer count}) * (\text{productivity factor}) \over (\text{number of features}) * (\text{defect rate})} \]

There’s no way to reduce these factors to a precise number, but every developer on your team has a pretty good feel for them:

  • Developer count – How many developers do you have who can and do work on different maintenance items?
  • Productivity factor – How much can your developers accomplish? How quickly can they work through any maintenance tasks?
  • Number of features – How complicated is your software? How many components and features does it have working together to deliver the required functionality?
  • Defect rate – How many bugs are there in the software? How often are you required to go back and rework something because it isn’t quite right?

A higher maintenance quotient is better. A higher value indicates that maintenance is performed quickly and efficiently, or that there isn’t as much maintenance to perform in the first place.

So how do you improve the quotient? With an understanding of the formula, keep the following things in mind as you build and work with your teams and processes:

  • Keep features and complexity to a minimum. All software has features, so maintenance will never be completely eliminated. However, be very careful about what gets added – and make sure the architecture of the features is done in a way such that overall complexity is well-managed.
  • Strive to be defect-free. It takes an entire organization to accomplish this, from senior leadership placing importance on these values all the way to junior developers and interns who are actively learning how to write the highest quality code possible. Completely eliminating all bugs isn’t reasonable, but good development, testing, and QA patterns can significantly reduce this.
  • Work to attract developers who are committed to quality. Then empower them to focus on quality and maintenance. Which brings us to the last item:
  • Make sure your developers have what they need to be productive. Give them the right tooling and processes, make sure that the pressure to release features is balanced with the need for maintenance, and ensure the team has time to QA their work before deploying.

Bugs and other maintenance issues have a compounding effect. Defer enough issues and they start to snowball – until it takes herculean effort to get them all under control.

In some ways software maintenance is like car maintenance – if your car is 50 miles over an oil change interval there’s no harm done; if you have a tight release that can’t be pushed and there are a few low-impact bugs that make it out, it won’t kill your company.

But – if you continually put your oil changes off for thousands of miles while ignoring the odd noise your engine makes when you start the car in the morning, you are going to eventually find yourself in the shop with a big expense and a lot of inconvenience on your hands. Put off software maintenance long enough and you eventually find yourself with a system that requires all your time just to keep it from completely collapsing.

The good news is that there are a few variables involved here, so you have the ability to affect the outcome:

  • Want to keep a small engineering team? Spend more money to hire the best so that the productivity factor is higher.
  • Do you need to add a large number of features, knowing complexity will creep up as you do so? Spend a bit more time and effort on defect management along the way and keep your maintenance quotient intact. Spending time on your architecture and design will be key as well.
  • Are you unable to build features because of the time you spend bug squashing? Devote some extra resources for a period of time to get those under control and put systems in place to minimize new bugs.

Everyone loves new features, but keeping this quotient in mind as you build can help prevent long periods of not being able to build anything new, because you are stuck doing extensive maintenance on what you already have.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.