The Source Code
This is one of the most precious assets of any development team because in it lies all of the work. In
is the only artifact that every project will always need to build. Many teams don’t document it, nor
types of tests for it, but without code, there is no software. So, code is the one thing that
development teams will always have. This provides the guideline that it’s a fundamental area to pay
attention to in
order to control quality and reduce risks and costs, no matter what the organization’s goals and context
When considering source code, we are referring to several things, but we’re mainly referring to code
management and code quality. Both aspects should be considered in order to achieve a good
With code being such an important asset, a risk that’s essential to have under control is making sure to
manage it and any amendments made thereto. There are specific tools to do this that are made for working
centralized repository where all team members can reliably store it.
Today’s tools have evolved in terms of task focus, going from simple schemes like CVS to more
flexible ones like Git. What they allow, some to a lesser or greater extent, is to have the code in a
location. Each developer can submit code, consult it, retrieve previous versions (which is useful when
your code is
not working properly and you need to go back to the previous working version), add comments to each
(e.g., comments indicating why one decided to send certain code to the repository) and much more.
These tools are also accompanied by a methodology. In particular, this is reflected in how the branches
versions are administered (approved, removed, merged, etc.), which allows for different people to work
versions of the code. There are those that maintain a branch for each customer (if each has different
code), or a
branch for larger versions of code, or at a finer level, where a new branch is opened for each
functionality or fix
On the other hand, it’s important to pay attention to the code quality for promoting maintainability.
quality is typically an internal attribute of quality, as it’s not visible to the user. It’s possible
though the user perceives a software to be of high quality (easy to use, fast, without critical bugs,
etc.), it can
actually have troubling code quality problems. But since users can’t see nor analyze the code
would never know. Conversely, quality factors like performance, reliability, and usability,
among others, are
external, meaning, users do perceive them.
But, there may come a moment when internal quality factors transform into external ones. Take, for
happens when a change is made to the system in response to a user request. If the code quality is so
poor that it
takes several weeks to modify the system, then there is a huge maintainability problem which not only
development team, but also the user. The longer it takes for the change to be made due to the bad code,
the user satisfaction will be.
Maintainability depends on many aspects. There is a tired phrase that goes, “Code is written once
many times,” meaning, it must be easy to read. But this doesn’t only include following the well-known
like when to use capitals and when to use lower case, or using the correct indentation, but it’s also
keep the code complexity, coupling, size of the classes, amount of parameters, and many more factors in
Years ago the term "technical
arose for easily explaining the problem of code maintainability to someone without programming skills.
It makes an
analogy with the more well-known concept of financial debt. It essentially says that if one schedules a
functionality, and does it hurriedly due to lack of time, without complying with the team’s "definition
(for example, skipping documentation by putting comments in the code, not meeting standards and coding
nor implementing unit testing) then at that very moment, “debt” accumulates. The system is owed whatever
it may be
that was hastily foregone, for example, unit tests, putting them off for when time allows.
What’s the problem with that? Besides repaying the debt, “interest” will be added on so to speak, since
likely to take longer and more energy to fix things after some time has passed than doing it right in
Each maintainability problem generates technical debt and someone always pays: sometimes just the
developer, or worse, the user who ends up suffering from the poor quality of the system.
Some very common defects in code quality are:
- Duplicate code
- Lack of unit testing, lack of
- Spaghetti code, cyclomatic
- Methods that are too long
- No adaptation to standards and
- Known security vulnerabilities
Modern development environments help immensely with some of these problems such as Visual
Studio or Eclipse (to name a few popular
ones), to the
point that if some of the restrictions are not met, the code will not compile. At any rate, there are
that can be analyzed with tools that were specifically made for analyzing code quality. Today, the most
tool for this purpose is SonarQube, but there
others such as PMD, Kiuwan
These tools perform a static study of code and are white-box, that is, they analyze the code without
it. They check for the common defects mentioned above, such as duplicate code or cyclomatic complexity.
Something very impressive is that SonarQube and tools alike are able to indicate what exactly the
is, calculating how many minutes it would take to resolve each issue it detects. For example, the
is shown publicly on the SonarQube site as the result for MySQL. One can see that the software has a
debt of 36,000
days, which means 36,000 days are needed to resolve all the detected incidents.
This much debt is not what anyone wants for their software!
While it’s great that SonarQube can provide information as to where the technical debt is, it is also
to know how to pay it. But, just sorting these issues by priority isn’t enough. The key here
the code that will give the best ROI if improved. It’s necessary to cross the information of the
their severity with the number of commits that there are in each class. In doing so, efforts can be
improving the maintainability of those classes that are modified more often. However, if there are
problems of classes that are seldom touched, but they function properly, it’s better not to tackle them.
saying goes, “If it ain’t broke, don’t fix it.”
To achieve continuous testing, a CI environment must be built, and to do so,
clear that code needs to be accessible in a well-organized repository, with various quality checks
on the code
being made, utilizing something like SonarQube.