Maintenance-Aware Mindset

The previous lesson clarified my view of handling application maintenance and support. I believe that these activities are the responsibilities of engineering teams who build systems. While this group tries to minimize or prevent technical problems and incidents, they need to employ various techniques to reach this objective. In this lesson, I will touch on a couple of topics that will help prevent issues after deployment as long as engineers keep these matters in mind.

Maintaining applications in practice

Engineering teams are responsible for maintaining applications that they built. At the same time, they need to continue developing new features. For this paradoxical arrangement to work, it is necessary that the group keeps an eye on a ratio of development versus maintenance efforts and takes course-correcting steps to deliver more features with less support.

In the early ages of an application, this task is easy to fulfill since there is hardly any maintenance necessary. When the system grows and the number of support requests spikes, the time available for building features shrinks. When this phenomenon happens, leadership often thinks that it is best to hire an additional dedicated team to handle maintenance activities and free up resources for feature development. This decision only poisons the engineering spirit; developers lose the need for quality work since maintenance is not their problem anymore, and things worsen over time. Therefore, I suggest taking an alternate route.

As soon as you notice that supporting an application takes an unacceptable amount of time compared to new feature development, you need to pause and brainstorm how to stop the trend. Concrete actions depend on the root cause, so I will list a couple of examples to give you some ideas:

• If maintenance is technical, such as performance or scalability improvement, you may need to treat this shortcoming as technical debt, and address it soon. Furthermore, develop a habit of systematically implementing technical capabilities besides functional features. Typically, engineering teams often do not pay attention to technical debt, and it grows exponentially and unnoticeably, so you must keep an eye on this tendency.
• Maybe support tickets indicate customers’ confusion due to unclear user experience or ambiguous input validation messages, which you have been treating as a low priority concern. In this case, you might need to make these improvements sooner than you had planned. By addressing these issues, you are decreasing the number of support requests and optimizing the anticipated versus unplanned work ratio, which will allow you to deliver more capabilities to your customers in the future. Hence, look at this adjustment as an upfront investment with good returns in the long run.
• Are you receiving the same kind of maintenance request over and over again? Perhaps it is time to think about automating resolution so that customers can enjoy self-service instead of waiting for a response from the team.
• If end users complain about broken functionality and bugs, you may need to review your automated test suite and improve coverage via unit, integration, functional, and end-to-end tests. These constructs exist to increase quality, so make sure to build and leverage them at all times.