How to Create Maintainable Application – Part 2 – Measurement

In the previous section, we explored the definition and the reason why maintainability is critical in a company.

When given a task to review or extend current functionalities in a codebase, the first thing I’d like to do is to assess the risk of side effects on the application. This would usually give a decent insight on how the application was developed and how mature the development practices are. A more mature team would have a decent codebase and a style being followed in unison. They are usually easier to understand as they follow a particular style even though they are written by different developers. At the end, it is a risk assessment activity that requires to be done to see how much of a risk it is to modify or extend the current functionalities. 

These are few ways to measure maintainability.

Lines of Code

The number of lines of code is a good indicator of how big a class is. In C# and .net world, a class is often written in a singular file. I have seen a program with classes of more than 10000 lines of code. When a class grows too big, it is an indicator of a broken SOLID principle. I have blogged about how to look for broken liskov substitution principle previously. The class had too much responsibility and at the same time crossed different boundaries of the business domain.

It is difficult to discern what number is acceptable in an application as it differs between each case. Measuring based on the lines of code can be the first test to look into deeper maintainability issues in an application. 10000 lines of code in a class is usually too much and 100 lines may be too little but could also be enough.

Cyclomatic Complexity

Cyclomatic complexity measures the number of decision points of a program. It is a measurement to indicate the complexity by measuring the number of linearly independent paths through a program’s source code.

A low cyclomatic complexity means a higher probability of a good maintainable application. Higher number means it would take more time to modify the application as there is a higher probability that it contains more use cases. An analysis using cyclomatic complexity can pinpoint areas in an application that can be improved.

Deployment Frequency

A high deployment frequency is an indicator of good development practice. The only way to achieve this in the first place is to have a good and maintainable application. The longer a program not in a production, the higher the probability that it would have a lower maintainability degree when it reaches production.

I have worked on an application that the last release to production was already in more than 2 years. They had to modify the application and re-release it. The production code, and what was in the repository was completely different. The code in the repository was buggy and broken, and could not be used.

Many things could happen before a code reaches the production. From scope creeps, the feature itself could become obsolete of its usefulness, to unknown and unperceived bugs that happens because of environment issues. All of these factors would add up and lowers the probability of the application being maintainable. Having a higher deployment frequency would reduce this probability.

The Next Developer Test

The next developer has a broader meaning in this case. It could literally mean the next developer that requires to maintain the code, or the next developer that sits next to you. It could also mean the same developer who wrote the code in 6 months’ time when a new feature request is required to extend or modify the existing code.

The next developer test happens by default when doing code review. However, the judgement here is not whether the code conforms to the team’s coding standard or framework, but whether the code can convey enough information of what the programmer’s intention and the business requirement for the application. The aim is to be able to have higher confidence level on the next developer when they have to modify the part of the application.

Final Words

There are no silver bullets in determining the maintainability degree of an application. All of the measurements described above must be used together. With enough practice, at best, an individual can only sharpen their intuition and have a better feel of these maintainability degrees and assess the risk when they require to modify or extend the application.

In the next section, we will look into a few methods on how to improve maintainability.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s