With the rapidly growing popularity of digital entrepreneurship and business process digitization, demand for software products is at an all time high.
Due to the accelerating demand, global competition, as well as other factors like the increased use of outsourcing, low development costs and faster time-to-market are quickly becoming top priorities over product quality.
“Why should I care?” you might ask.
If you are planning to, or already in the process of developing a software product, ignoring the quality side of the process can easily lead to wasting the entire development budget and severely hurting your business.
Throughout our work we’ve encountered many software projects that were struggling to move forward because the code base had gotten so unstable that it was difficult, or straight up impossible to develop further. In a few cases, more than 12 months worth of development investment would have resulted in an unusable product without intervention.
The goal of this article is to highlight the importance of maintaining high source code quality throughout the software product life cycle. We will talk about the possible effects of low-quality code on your project (and entire business) and list effective ways to ensure high product quality.
To avoid being vague, first let us try to elaborate on what we mean by high source code quality.
High quality code means that your source code must perform well with regard to the following:
Now that we’ve established what high source code quality actually means, you probably have an idea about what poor code looks like. If a code base is lacking in the qualities listed above, it is considered low quality.
To be more specific, low-quality source code:
In our opinion, it’s a bad idea to wait to check the quality of your product’s source code before live release. By that point, fixing these issues becomes much more expensive and time-consuming than it should be.
This is why source code should be written following high quality standards in the first place. We talk about ways to achieve this in the sections below.
Technical debt is “a concept in software development that reflects the implied cost of additional rework caused by choosing an easy (limited) solution now instead of using a better approach that would take longer.”
It’s pretty much the software development term for sweeping issues under the rug that you’ll have to deal with later. Constantly choosing the easy way out has real consequences for long-term projects. Too much technical debt can eventually cripple the development process entirely.
Technical debt has to be “paid” sooner or later. Even if you change development teams mid-way, the new team will have to deal with the extra work left behind by their predecessors.
Simply ignoring mandatory periodical maintenance and refactoring tasks also creates a lot of technical debt during long projects.
Dilbert by Scott Adams
The symptoms of low-quality code only start to appear in later project stages, by the time software features are getting more complex. This only makes them more dangerous.
If developers don’t review the source code frequently, by the time they notice something’s wrong, it’s usually too late. Development tasks start to take longer to complete, bug fixes take up more and more of the team’s time, missing deadlines and prolonging crucial updates.
Spaghetti code causes even more headache if there is a decent amount of fluctuation in your development team. New developers will have trouble understanding the code base and it will take weeks until they can effectively contribute to developing it further.
Poor code quality also makes it impossible to predict how long it takes to add new elements without breaking others. This causes future development estimations to become highly inaccurate as well.
From a business perspective, software product development is an investment from which you expect a return – so just like any other. This return can come in the form of revenues if we’re talking about an SaaS solution, or cost savings and increased efficiency if we’re talking about software for internal, organizational use.
However, with a low-quality product that doesn’t sell, or effectively improve internal processes, your chances for a return drop significantly. In more severe cases, if the final product doesn’t reach live release at all, the development project can be considered a complete loss. This can mean multiple tens or hundreds of thousands of dollars worth of pointless spending, which can be crippling for most businesses.
If you can’t maintain an acceptable level of code quality, the “best case” scenario is that you’ll eventually get a working product, but at a much higher total investment cost.
Poor source code quality can also negatively impact customers’ perception of your product, and the whole organization. If a new release receives overly negative reviews from early users, it will take a lot of time and effort to win them over. While experience shows this isn’t impossible, it’s still better to prevent a fire from starting than having to put it out!
If you don’t have the necessary technical knowledge, it will be difficult for you to assess code quality without help from the development team. You’ll most likely only notice client-side issues related to speed, device compatibility and others directly affecting the user experience.
A good practice is to ask for frequent reports from the development team (sprint reports, release reports, etc.). These reports must contain the key project and code quality indicators. If you don’t have a technical background, ask the team to explain these indicators as many times as necessary.
If you still need help evaluating them, you can hire a third-party consultant who could even check the source code if necessary. If this is not an option, however, the development team must introduce their own quality assurance and code review processes for quality management.
Quality assurance, or QA should be an essential part of the software development life cycle. Its goal is to validate the quality and functionality of the software before release, and make sure that the final product provides the best possible user experience.
Note: QA focuses on testing the quality and functionality of new product versions, not the source code directly.
However, quality assurance still plays an important role in detecting bugs and errors in the software before it gets released.
Here are a few widely-used types of quality assurance:
Code review is also a kind of quality assurance activity, where a software developer checks if the written source code complies with coding conventions and style standards. It is also used to examine whether the best possible technical solution was used by the developers or not.
Apart from manual code reviews, there are also a lot of automated tools available for static and dynamic code analysis.
Code review is a process by which developers review each other’s source code. The two roles present in a peer code review are:
Some commonly used code review methods:
Apart from improved source code quality, code reviews also make it easier to train new development team members. In the long run, they lead to the team having a more consistent coding style overall, improving the whole development process as well.
For both larger and smaller code bases, your team will likely have to use automated code analysis tools as well. The difference between static and dynamic code analysis is already in their names.
Static code analysis tools examine the source code without executing it. Dynamic analysis is conducted while the code, or a part/unit of it (for example unit or integration testing) is being run. Code analysis tools help developers save a huge amount of time on fixing errors by identifying them in a matter of seconds.
Our own team mainly uses these code analysis tools:
For version control:
There is no such thing as a perfect, one-size-fits all development methodology for all teams and all industries. The recommendations in this section are based on our own experience and preferences.
Note: While the main topic of this article is code quality, these development methodologies also focus on assuring the overall quality of the finished product.
We recommend using an Agile methodology based on Scrum or Kanban. Scrum in particular can be very beneficial for product owners to keep a close eye on the project’s progress. Frequent communication and product demos allow you to have a good overview of the newly completed features and even test them yourself.
This methodology also helps your team break down large and complex projects into smaller, more manageable chunks called sprints. These are 2 weeks long by default, and they contain a previously agreed-upon set of user stories and development tasks.
Scrum board example
As for team composition, QA experts and senior code reviewers should be integral parts of both small and larger teams. We also recommend to regularly include less experienced developers as code reviewers for training purposes. In these cases they must still be assisted by a senior colleague.
If you have to coordinate the work of multiple parties, a dedicated project manager can also be a valuable addition to the crew.
Here is an example of our own team’s composition for most projects:
As I mentioned at the beginning of this section, there is no such thing as a one-size-fits-all methodology. Copy-pasting the Agile manifesto for your team won’t be an ideal solution.
This is why we only recommend it as an outline for your process. It will be up to you and your team to optimize each aspect of the methodology to fit your organization and in-house team composition as much as possible.
We also do this sprint after sprint with our own clients, which is why we recommend it to others. For example, it might not make sense for a small team to hold daily stand-up meetings, if team members are working really closely together and they already know what everyone is working on at all times.
In these cases, it might be better to organize a single, longer weekly team meeting instead. It should also be examined whether sprint planning and retrospective meetings work effectively in their standard forms, or if they could be organized in a better way.
Most other aspects of this methodology can be optimized in similar ways as well.
While low code quality is rarely among the leading agenda during product management meetings, it is an increasingly important topic for businesses that rely on custom-built software to grow.
Apart from drastically increasing development costs and time – hurting profit margins -, low source code quality also negatively impacts customer satisfaction.
When it comes to software products, you only have a few seconds to form a positive first impression with users. If their first experience with your product is slow, clunky, or results in a crash or any kind of bad experience, you will need to invest a lot of time and effort to better their opinions.
Instead of having to put out the fires, prevent them by integrating coding standards, quality assurance and code review into your development process as early as possible. While it may just seem like extra work early on, it will most definitely save you a lot of headache and resources in the long run.