Maintainability

Table of Contents


MAINTAINABILITY

TTM ROI Sellability Agility Reputation

Maintainability is the ability to change an existing solution with relative ease (note this is subtly different to extending, or switching out behaviours). Solutions are broadly categorised as having high, medium or low maintainability qualities.

Generally, solutions exhibiting a high level of maintainability benefit the entire enterprise, facilitating change with faster turnaround times and of greater quality; this has the knock-on effect of increased Stakeholder Confidence in the product (e.g. fixes are resolved efficiently and accurately) and, potentially, results in a more sellable solution (due to higher quality).

A highly-maintainable product is characterised by the need to make a modest number of changes (in an existing area of interest), to enhance or fix existing behaviours. But, there are additional benefits; the ability to easily read and understand code is vital, as is the ability to easily identify specific areas of responsibility.

In terms of readability; the ease with which developers can understand code correlates to effort. Domain experience is another very important (and often neglected) aspect of engineering (alleviated somewhat by Cross-Functional Teams ensuring all change occurs through one of the owners). Developers who are constantly forced to analyse and understand how something works are not focused on solving the problem; they are attempting to align themselves (contextually) in order to then identify and solve the problem. This is inefficient - the more obstacles placed in front of a developer, the higher the effort, the longer the delivery lifecycle, and the more impatient our customers are.

WARNING

Documented code is more than a luxury; it is vital to ensure highly-maintainable software.

Source code location and package structure (logical groupings of similar responsibilities) are other important aspects of maintainability. Similar responsibilities should reside in logical (easily identifiable and discoverable) locations to create high cohesiveness, not strewn across distinct units. This promotes Smart Endpoints and demotes disjointed maintenance practices requiring coordinated releases.

Employing SOLID (Single Responsibility, Open/Closed, Liskov, Interface Segregation, Dependency Injection) principles [1] is another aspect linked with maintainability. Loosely-coupled, highly-cohesive, and closely-situated code is easier to identify, change, and carries less risk.

MAINTAINABILITY & EXTENSIBILITY

The key difference between maintainability and extensibility is that maintainability is concerned with the ease of modifying the existing code-base (possibly to fix bugs), whilst extensibility focuses on the ease of adding new functionality to an existing solution.

PILLARS AFFECTED

TTM

A business’ ability to react is affected by its ability to easily modify an existing solution (in conjunction with its Releasability). This makes maintainability a very important consideration - however, there's two aspects to consider:

  1. Immediate needs, or lifespan.
  2. Medium-to-long-term needs.

Writing poor quality code may suit immediate needs, but it won't likely satisfy medium-to-long-term aspirations. Therefore, we should first understand the context in which the software is needed, and any constraints the business deems important. For instance, does the business have an immediate need for a solution, such as to present it at a looming trade show? Alternatively, is the solution a one-off, to be shortly discarded? In both cases, there's little immediate benefit to be gained by building in quality early - in fact it may create waste.

ADVANCEMENTS

It's ok to build something rough-and-ready for an immediate need, and then refine it afterwards for a sustainable approach.

However, if the business intends to build upon the solution over the next few years, then easy maintenance is critical (40-80% Maintenance Mode).

EXAMPLE

I once worked at an organisation who outsourced part of the development for a new product to an external team. Unfortunately - and against my advice - the external team was left to their own devices for too long, and hadn't introduced foundational principles to support maintenance. What was delivered was below par (e.g. poor error handling and cohesiveness, lots of duplication, lack of consistency / Uniformity), causing frustrations on both sides, reducing Stakeholder Confidence, and placing the entire partnership at risk.

Our internal team spent a week per microservice, refactoring it to introduce appropriate foundations and enabling future changes to be more efficiently delivered.

ROI

If the cost of maintaining software is high (possibly due to system complexity, a Single-Point-Of-Failure, or in an area with poor releasability), then it's expensive to make changes. This wouldn't be an issue were we never to touch an existing solution after its release, but that's rarely the case.

If 40-80% of our time is spent in maintenance (40-80% Maintenance Mode), then we must remain highly effective in this mode to ensure a good return. This might (for instance) take the form of clean code and design, high cohesion and loose decoupling, encapsulation, quality documentation/comments, automated testing, Testability, or the standardising of code or APIs.

SELLABILITY

Some customers (existing and potential) may view the time (and cost) of each change as detrimental to sales. Businesses that can respond quickly to customer needs are likely to do better (and live longer) than those that can't.

REPUTATION

Software with a poor structure, design, or quality, can hamper Reputation, as it slows the entire value delivery pipeline. In the case of missed SLAs, this may have financial penalties; in the case of a general delivery tardiness, this may have sales implications.

FURTHER CONSIDERATIONS