The main indicator of a complete software product is the presence of all necessary features. It is the working functionality that end-users, investors, testers and managers see and use.
Generally, features are quickly added at the initial stages of development, while the system is stable and a small QA team is enough to test it. It is also easy to predict the price of the added functionality in terms of money and time.
Developers don’t always have enough time to create a proper project architecture and think about the technical debt. Furthermore, it often occurs that customers try to reduce the project cost and hire developers of doubtful skills.
When the project reaches a certain degree of complexity and is deployed to the production environment (where there already are active users), it becomes more difficult to add a new feature and predict its cost, the system loses its stability and requires more effort from developers and testers.
Eventually, the system can become so unstable and difficult to maintain that it’s easier to create a new version from scratch which in turn requires huge one-time expenses. It’s also likely that the new version of the system will end up like the old one.
The reason for that is the following: when the number of lines of code and the project complexity increases, developers will need more time to introduce changes and add new code. Thus the technical debt of the project grows.
However, if the development team follows certain rules when coding and creates an accurate system architecture, adding new features will cause little or no increase in technical debt.
In order to manage the technical debt, software engineers must establish a development process with certain quality requirements to the source code, that also must be systematically controlled (by senior employees and automatic systems).
To write high-quality code, one needs a strong team of developers with good technical culture. However, it is sometimes difficult to clearly understand the real level of the team at the initial development stages.
To determine the skills of the team, one can assess code according to certain metrics as well as use automatic tools for code analysis and high-level reports generation that can help track problem issues of the system on time.
The good news the fact that we can obtain all necessary information for tracking through automatic tools for static code analysis. Let's consider the most effective:
SonarQube – for code quality control.
Jenkins – for automating building processes, Unit Tests, and code quality control.
Unit testing - for checking the app logic automatically as well as operability of the app according to its requirements.
Metrics that can be used for assessing code quality
1). Code coverage
In an ideal project, any code must be covered with low-level tests according to white-box testing. In order to reach broad test coverage, we use TDD and BDD development methodologies that imply creating tests before the (working) code is written.
As mentioned above, 100% test coverage is desired for an ideal project. However, in reality, we have to make concessions to make software product development faster, that’s why it is good enough to have code that can be at 80% or more covered with tests.
2). Vulnerabilities
There are no perfect apps. There are no computer systems with perfect security. For project success it’s necessary to track any potential security problems: from an absent-minded employee who has forgotten to check and screen the input data to published famous vulnerabilities on platforms, languages used libraries.
Security is a cornerstone in the projects of any level of complexity and we must be sure that user data will be protected.
3). Code style and cyclomatic complexity
These characteristics influence the readability of code and how all developers in the team perceive it. This in its turn affects the project velocity as well as the speed and costs of introducing changes. Cyclomatic complexity of code also affects its performance predictability.
4). Code cohesion (complexity and size of dependency tree)
That’s quite simple – the higher the cohesion, the more system components are affected by changes. High code cohesion can result in project instability and increase the cost of each change by tenfold.
5). The number of code lines
This metric allows defining positions in code with the higher number of changes as well as detect the most bloated code fragments that must be carefully examined during refactoring.
When software product development process is established appropriate, if the right analysis and automation tools are used, one can be sure that the quality of the project implementation will allow it to be supportable and stable for a long time.
Learn more about how no-technical customers can be sure in product quality and how they can check maintainability of the delivered code.
Top comments (1)
I'm currently trying to convince my lead developer to implement SonarQube as a tool to monitor our software quality. This article comes in handy - thanks :D