3 Aspects of a Great Software Maintenance Team

Good software is never done. This is even true for software that could be considered “feature complete.” There may come a time when there are no more opportunities worth chasing by adding to a product. However, there will always be a need to ensure it continues running smoothly.

While the bits in your software don’t literally rot, the platforms, libraries, and standards it was built upon will evolve. If not consistently maintained, your software will belong to the past and not endure in the present. To avoid the unpredictable costs of updating mothballed software, you need a great maintenance team — even if it’s only one or two people. There are three aspects that I believe make the best software system maintenance team.

1. Build Your Team from the Builders

The best people to maintain software are the folks who built it. This might seem obvious, but it’s often ignored in practice. I would take this point one step further and say that folks on the original implementation team should expect to be the people who maintain the system until it reaches its end of life. This will motivate the team to take more care with their work because they know they’ll be on the hook to ensure it holds up.

Maintaining software isn’t necessarily easier than building it out in the first place. A maintenance team isn’t the place to try and save money by going with a lower-cost option.

2. Focus on Preparedness

When implementing an initial release, the focus is on maximizing throughput without sacrificing quality. But a maintenance team should focus on being prepared to respond.

The goal of all maintenance work should be to make the next batch of feature work or issue resolution fast, easy, and safe. Some maintenance work could even eliminate potential future issues. This fundamentally shifts the team’s mission and is a core foundation to a maintenance team’s success. It also fundamentally changes the nature and priority of the work a maintenance team will be doing

Almost all maintenance work should be determined and prioritized by the development team. This is a large shift from product development mode, in which we collaboratively build the backlog of work, but setting priority ultimately lies with the client. We want the maintenance team to know it’s their responsibility to stay 100% informed on important issues (security alerts, platform updates, third-party vendor changes, etc.) and build a plan to deal with them.

New features and enhancements to existing functionality should be handled separately from maintenance tasks. New feature work should be a temporary shift in the team’s focus (from maintenance to implementation) and should temporarily increase team allocation. By requiring an explicit shift in the team’s mission and a calculated increase in team allocation, we can both 1) achieve a shift in decision-making responsibility with regards to work definition, and 2) responsibly size the team so the maintenance work isn’t simply drowned out by a never-ending backlog of enhancement work.

3. Rotate People Through the Team

Committing to a rotation schedule accomplishes three important things for a maintenance team.

• It ensures you have a deep bench of expertise to draw upon in the long term.
• It continues to test the ability to bring someone new into the codebase. This should drive a natural, evergreen reason to maintain appropriate documentation and on-boarding practices.
• It helps you avoid a lone developer taking shortcuts for which they excuse themself, thinking: “I’ll be the only one who has to live with it.” Fresh eyes are always good in any software team, as is knowing that someone else will be looking at your work.

Maintenance teams are an important part of ensuring that software continues to deliver value and is able to have future value added to it.