Factors Influencing Software Maintainability

Dr. Vanya Ádám

Introduction

In our previous blog post, titled “What Is Software Maintainability”, we introduced the concept of software maintainability and argued that it is important to control it. Carrying out the necessary control actions is only possible if we know which the influencing factors are. Describing these factors is the topic of this blog post. By monitoring and influencing those factors, one can control software maintainability.

The Influencing Factor

How easily a software system can be changed depends directly on two major factors: the state of the source code that needs to be changed and the developers executing the modifications. Let us look at the source code first. During the maintenance process, the source code is browsed and read by the developers to understand where and what should be changed. Most of the time, this means reading through source code written by other developers. The efficiency of this process is influenced by many source code properties. For instance, a well-structured software with small methods containing only a few decision points makes the process quick and efficient. On the other hand, a poorly structured monolith with huge methods having many decision points slows the process down enormously.
After analyzing the source code, introducing modifications is what developers do during the maintenance process. Also in this phase, the source code properties play a relevant role. For example, let us consider a situation where changing one duplicated code segment requires changing another one to carry out a consistent change. This extra work degrades the efficiency of the maintenance process. Also, such a situation could have been avoided by eliminating or not even introducing duplicates: duplicated code can often be extracted to methods which can then be called from multiple contexts. The mentioned situation causes further issues. If a developer forgets to change all the instances of the duplicated code segment then the inconsistency introduced will likely lead to errors or unwanted behavior. Fixing such errors requires extra maintenance time and effort spent.
When a developer believes to be ready with the implementation of a given functionality then it is time to test it. Proper testing covers all execution paths in the code so that all execution possibilities become checked against the requirements. Whether it is possible to test a piece of code properly and to which extent depends greatly on how the code is written. Decision points (like the ones introduced using if statements) in the code increase the amount of possible execution paths in the code to be checked. Methods with many decision points take a long time to test because of the amount of test cases which need to be implemented. Furthermore, there is a risk that only the most relevant test cases will be implemented because of time pressure and all the other execution paths will remain untested. This introduces the risks of executing bugs during production time and causing availability issues or unexpected behavior.
Sometimes, due to how the code is implemented it is not even possible to test a piece of code as a unit. For instance, consider the an important portion of a very long method or an embedded SQL statement. To overcome these limitations, methods should be small and embedded SQL statements should be avoided when possible. Disregarding these guidelines can lead to untested code and also code duplicates with the risks already described. The software maintenance activities mentioned above are further clarified in the 14764:2022 ISO/IEC standard. For this, please refer to [1]. As for the source code level properties (which also known as metrics), Zou and Kontogiannis in [2] provide a more systematic description.
Let us now look at the second major factor that influences maintainability: the developer. Giving the same development task on exactly the same codebase to a senior and a junior developer would most probably result in different execution times of the necessary code changes. That is because a senior developer has more professional knowledge and experience than the junior developer. Next to that, the senior developer is likely to alter the code in such a way that the altered code will be easier and faster to maintain for the next developer who will work on those altered code segments.
Independent from the level of professional knowledge, developers also have a certain level of cognitive capabilities. For instance, how many things can they remember at the same time. Such cognitive capabilities can influence how much time developers need to spend scrolling a long method up and down on the screen before the analyzed method is understood. For those developers, who can remember fewer things at the same time, it takes longer to analyze and modify the code. Even if developers do have the necessary skills to create code which can easily be modified there are two further reasons why they would not do it and as a consequence why they would degrade maintainability. The first reason is the lack of motivation. Just as everyone, developers also need to be motivated to do things in a certain way. A self-respecting and experienced programmer typically has internal motivation to write maintainable source code. Other programmers may need to be motivated with sanctions and rewards to do the same. Sanctions can come, for instance, in a form of decreased bonus or even dismissal. Rewards could include advancing in positions with a salary increase and more respect. The second reason is the lack of possibilities. In case a developer is skilled, experienced and motivated but is not provided the needed resources (for example, there is an extreme time pressure) then shortcuts will be applied. Since functionality is the number one priority in most development companies, this means developers will spend less time on maintainability. Even though this shortcut seems to be a solution in the short run, developers will spend more time because of the maintainability issues introduced in the long run. There is no escape, technical depth needs to be paid back with all the coupled interest. The concept of technical depth was coined by Ward Cunningham in [3] and it has received growing attention ever since.

Summary and Conclusions

One way or another, software maintainability is affecting you. It can have a significant impact on your career if you are working for a software development company and it is a major factor to consider when you invest in such companies or buy custom software. Therefore, we believe maintainability has to be understood and be controlled explicitly to reach your goals. To help you get in control, we described and discussed the two major factors influencing software maintainability: the state of the source code and the developers. We argued that without properly crafted software and sufficiently skilled, cognitively capable, motivated and enabled developers it is not possible to reach an acceptable level of software maintainability. The next blog post in our series on software maintainability will elaborate further on the potential effects of maintainability. With these blog posts, we hope to increase awareness about software maintainability, help you control this concept and start constructive discussions about it. In case there are certain things described in this blog post you do not or not completely agree with or if you think it should be extended in some ways, please feel free to contact us and tell us about your idea: [email protected]

References

[1] ISO/IEC 14764 (2022). ISO/IEC 14764:2022, Software Engineering — Software Life Cycle Processes — Maintenance [2] Zou, Y., & Kontogiannis, K. (2002). Migration to object oriented platforms: a state transformation approach. International Conference on Software Maintenance, 2002. Proceedings., 530–539.
[3] Cunningham, W. (1992, December). The WyCash portfolio management system. In Addendum to the proceedings on Object-oriented programming systems, languages, and applications (Addendum) (pp. 29-30).

Source code cloning, also known as copy and paste programming is believed to be a major threat to software systems, mostly the ones currently in their implementation phase. The problem is often overlooked due to the true danger lies in the clones' long-term existence, specifically in their unmonitored evolution – hence the immediate negative impact cannot be observed. When a clone instance of a given method needs maintenance (bug fixing) or further code development (enhancement), usually the tasks would require to be performed on the other clone instances as well for the consistency to remain.

Estimating development costs could be a problematic task. There are a huge number of details that should be taken into account for the calculation, the most important of which probably is the maintainability of the source code. It is axiomatic that maintainability has an immediate effect on development cost, because the less maintainable the software system is, the more expense is needed to develop it.

Code clones (the products of code cloning or copy and paste programming) can be a menace when it comes to long-term source code maintainability. While they seem harmless at first, they will do their damage after a few development iterations – exactly when it is too late for an easy fix. Neglecting to manage clone instances along with each other during a bug fix or a feature development of any of them will likely result in the inconsistency of the source code.

In this case study, we demonstrate how Qualysoft – a software development company present on the international market – determined the future development and maintenance costs of a software project using QualityGate.

The following case study shows how the QualityGate source code analyzing and management system has been introduced into a bank environment as an SLA measurement tool – as well as the installation process and the most important experiences of the introduction and pilot period.

The following case study shows how QualityGate gives an objective, important quality characteristic which was somehow rarely calculated in the past. This characteristic helps the client choose the development company suitable for his needs. The case study also shows how this newly introduced attribute affected a client’s decision. We recommend it to anyone who thinks to find the best developers is of key importance.

In this case study, we demonstrate how Qualysoft – a software development company present on the international market – determined the future development and maintenance costs of a software project using QualityGate.

The Dropwizard.io–Dropwizard GitHub project(https://github.com/dropwizard/dropwizard/tree/master) provides a Java framework for developing ops-friendly, high-performance, RESTful web services. It contains a glue code which makes a set of stable and mature libraries from the Java ecosystem working together, like Jetty for HTTP serving, Jersey for REST modelling and Jackson for JSON parsing and generating. One of the main goals of this project is to enable creating fast Java web applications efficiently. Dropwizard has out-of-the-box support for sophisticated configuration, application metrics, logging, operational tools, and much more, allowing one to ship a production-quality web service in the shortest time possible. The popularity of this open-source GitHub project can be described with more than 7900 stars (indication of how many people like this project) and more than 3300 forks (indication of how often the codebase was accessed).

The Alibaba – Sentinel GitHub project (https://github.com/alibaba/Sentinel/tree/master) provides a powerful flow control to increase the reliability between the services of distributed systems. It takes "flow" as the breakthrough point and covers multiple fields including flow control, concurrency limiting, circuit breaking, and adaptive system protection to guarantee the reliability of microservices. The popularity of this open source GitHub project can be described with more than 16200 stars (indication of how many people like this project) and more than 5600 forks (indication of how often the codebase was accessed).

The Google – Auto GitHub project (https://github.com/google/auto/tree/master) provides a collection of source code generators for Java. A Java implementation is usually full of code that is mechanical, repetitive, typically untested and sometimes the source of subtle bugs. The Auto subprojects are a collection of code generators that automate writing such code without bugs.

The CTrip – XPipe GitHub project (https://github.com/ctripcorp/x-pipe/tree/master) provides Redis multi-data center replication management. It realizes low-latency, high-availability Redis multi-data center replication, and provides one-key computer room switching, replication monitoring, and abnormal alarm functions.

The popularity of this open source GitHub project can be described with more than 1400 stars (indication of how many people like this project), more than 432 forks (indication of how often the codebase was accessed).

The Iluwatar – Java Design Patterns GitHub project provides a codebase with Java design pattern implementations. The implementations have been developed by experienced programmers and architects from the open source community. The source code examples are intended to be programming tutorials on how to implement a specific pattern. Next to the implementations of the design patterns, this open source project also helps developers with textual descriptions of the patterns.

The TechEmpower – FrameworkBenchmarks GitHub project provides representative performance measures across a wide field of web application frameworks. The project presently includes frameworks on many languages including Go, Python, Java, Ruby, PHP, C#, F#, Clojure, Groovy, Dart, JavaScript, Erlang, Haskell, Scala, Perl, Lua, C, and others. The current tests exercise plaintext responses, JSON serialization, database reads and writes via the object-relational mapper (ORM), collections, sorting, server-side templates, and XSS countermeasures.

The Apache – Shardingsphere-elasticjob GitHub project (https://github.com/apache/shardingsphere-elasticjob/tree/master) became an Apache ShardingSphere sub-project on May 28 2020. Through the functions of flexible scheduling, resource management and job management, it creates a distributed scheduling solution suitable for Internet scenarios, and provides a diversified job ecosystem through open architecture design. It uses a unified job API for each project. Developers only need code one time and can deploy at will.

In our previous blog post, titled “What Is Software Maintainability”, we introduced the concept of software maintainability and argued that it is important to control it. Carrying out the necessary control actions is only possible if we know which the influencing factors are. Describing these factors is the topic of this blog post. By monitoring and influencing those factors, one can control software maintainability.

The Effects of Software Maintainability

by Ádám Vanya

In our previous blog post titled “Factors Influencing Software Maintainability”, we analyzed the main factors having an impact on software maintainability. It helped us enumerate those things that we can monitor and change to get in control. In order to properly understand the importance of such control, we need to know what and how the level of software maintainability affects. This is the topic we are about to explore in this blog post.

In our previous blog post titled “Factors Influencing Software Maintainability”, we analyzed the main factors having an impact on software maintainability. It helped us enumerate those things that we can monitor and change to get in control. In order to properly understand the importance of such control, we need to know what and how the level of software maintainability affects. This is the topic we are about to explore in this blog post

In our previous blog post titled “The Effects of Software Maintainability”, we reviewed what maintainability can potentially influence. To manage the actual consequences, we must be able to control maintainability itself. This requires decision making and the execution of all the supporting actions. The decision making process applied can either be intuition- or fact-based. In this blog post, we will learn about how to measure the maintainability of software systems to extract facts for reliable and well informed decisions.

In our previous blog post titled “The Effects of Software Maintainability”, we reviewed what maintainability can potentially influence. To manage the actual consequences, we must be able to control maintainability itself. This requires decision making and the execution of all the supporting actions. The decision making process applied can either be intuition- or fact-based. In this blog post, we will learn about how to measure the maintainability of software systems to extract facts for reliable and well informed decisions.

In our previous blog post titled “Measuring Software Maintainability”, we explained why it is important to measure the maintainability of software systems and how it can be done. Based on the measurement results, some questions arise. For instance: Is the measured level of maintainability sufficient? Which level of maintainability should be targeted? How far is the measured level of maintainability from the targeted one? By when do we want to reach the targeted level of maintainability? Answering these types of questions is crucial since the answers given determine the decision and actions one must take to properly control maintainability. If you are interested in those answers please keep on reading through this blog post.

In our previous blog post titled “Sufficient Level of Software Maintainability”, we looked at the different approaches one can use to determine when the level of maintainability is sufficient. In case this level is not reached yet, actions need to be taken. Based on the results of the direct and indirect measurements of software maintainability, one may decide to invest in improving the level of maintainability. This blog post explains how it can be done.

Lines of Code is one of the most controversial source code metrics in software engineering practice. It is relatively easy to calculate, understand and use by the different stakeholders for a variety of purposes – that is why it is the most frequently applied measure in software estimation, quality assurance and many other fields. Yet, there is a high level of variability in the definition and calculation methods of the metric which makes it difficult to use it as a base for important decisions. Furthermore, there are cases when its usage is highly questionable – such as direct programmer productivity assessment.

Hopefully, the reader is convinced by the earlier blog posts that software maintainability is a relevant topic that needs careful attention and also actions taken. In our previous post titled “Improving Software Maintainability”, we focused on those actions which can be carried out to increase the level of software maintainability. Executing these actions costs significant effort. What we should keep in mind when reasoning about such investments is the main topic of this blog post.

Whether you are an owner, a manager or a developer of a software company, the extent to which you succeed in reaching your short and long term professional goals also depends on how maintainable the developed software is.

Since software maintainability is such an influential concept, we strongly believe that everyone should have a clear picture about what it exactly is, which factors are influencing it and how it can affect your goals set. In order to minimize the negative effects of a poorly maintainable system, one also needs to know what the current level of software maintainability is, evaluate if that level is sufficient and take the necessary corrective actions.

By publishing a series of blog posts, we intend to provide you with all the relevant information on software maintainability that is needed to understand and control it. This very first blog post introduces the subject of software maintainability.