Code Quality - What is Good Code and Why It Is important for Your Company?

Many articles have been written about what characterizes good code, how to write good code, and why good code is… good from the programming side. We can easily find them online and on our blog. Today, however, we want to approach the impact of good (or bad) code on software from the business side. Why is it not worth saving money at the beginning of creating a new system and how bad code can generate huge costs in the future?

Code quality - what makes good code?

Here comes the first problem. As developers, we can easily assess, even after an initial, rough analysis, whether the code is good or not. We're able to point out specific errors and explain why the used solutions are wrong. However, how can the quality of code be assessed by the person who buys the software, i.e. the client who's completely unfamiliar with it?

While using the application, it's difficult to assess whether it's based on good code, especially if it hasn't been made public yet and isn’t widely used. However, there are two signs that may appear and alert us that there's something wrong with the software.

Speed of operation

If we've just bought a system from a software company (regardless of whether it's a mobile application, website, or web application), we should pay particular attention to the speed of operation. If there are performance problems at the very beginning, they'll certainly get worse in the future. A freshly written application shouldn't run slowly. If the server on which this software is located has a problem with handling a single visitor, it certainly won’t be able to handle all its users when a thousand or even several thousand people start using the application at the same time.

Stability of operation and lack of errors

Typically, building an application is carried out over several stages. First, the developers create the alpha version, then the beta version, then the RC (release candidate) version, and finally the production version. The first two versions (alpha and beta) may contain bugs and using such applications may be a nuisance. However, these aren't versions intended for public use, but for testers. Every reliable software development agency has appropriate procedures that allow for finding and fixing bugs from the first versions.

Therefore, if we receive a final product that contains errors, it means that the testing team either slacked off or the company doesn't have one at all, and applications are released without checking them.

Unfortunately, the above two symptoms may occur quickly, but they don't have to. Then if we get an application that's poorly written but still works in a fast and stable manner, what's the problem? Let us explain.

Bad code may ruin your budget

The fact that problems with the speed and stability of the application haven't occurred since the beginning of its use doesn't mean that they won't appear in the future. Problems that haven't been detected right away will make themselves known. However, when we don't know about them yet, we - as software owners - take up a kind of technical debt (a situation in which seemingly easier and simpler solutions turn out to be less profitable in the long run). We leave dealing with the problems for later. Unfortunately, over time, there'll be increasingly more of them, and their repair will become more onerous. Let's look at the scenario that happens very often.

At the beginning, the client chose the cheapest offer among software companies and got an application with bad code. Initially, everything worked fine, but over time, more and more problems began to appear. The software was slowing down and customers were leaving because they were unhappy with it due to instability and constant crashes. The application owner finally had enough and decided to hire another development team, now for a higher price, rightly expecting that along with the price, the quality of provided services would also be higher. The client had high hopes for the new development team, knowing that the code needed to be improved. In this situation, only two scenarios were possible:

• writing the entire application from scratch, which would be associated with huge costs,
• repairing, piece by piece, what is already there (which would also mean very high costs).

Writing the application from scratch

Writing the entire application from scratch may seem like a good idea. We'll finally be sure that the code quality will be high and the application will work in a stable manner. Unfortunately, as we wrote earlier, that'll be associated with huge costs. The money we've initially spent on creating new software will be lost, and we'll have to invest more.

Let's also remember that we're considering a scenario in which the application is already running and customers are using it. Even if we start building a new application at the same time, we'll still have to incur the costs of "patching" the errors in the old system on an ongoing basis. In addition, creating a new solution will involve data transfer, changing their structure, etc. During this process, the running application will have to be turned off for at least a few hours, and the customers won't be happy about it.

Fixing the current application

The second possible scenario is to fix, piece by piece, the existing code. This solution also has its drawbacks. Firstly, as in the previous scenario, we'll still have to fix the existing errors on an ongoing basis, which will obviously increase the costs. In addition, such an operation must be planned with surgical precision. It takes a lot of time to analyze and figure out each step. Much time should also be spent on writing automatic tests so that when fixing one functionality, we can be sure that we won't accidentally break something in a completely different area. The entire repair process is very time-consuming and risky.

We aren't able to easily indicate which of the two described scenarios is better. Each of them has its drawbacks. Making a decision must be preceded by a detailed analysis of the situation, application characteristics, code quality, and costs.

Good code is an investment

Very often during their search, the client asks for a project estimation from different companies and then compares the offers. There's nothing unusual or bad about this. The problem arises only when the price is the only or key criterion when choosing a company. It’s difficult for a person unfamiliar with programming to understand why one company will carry out the order for 3 thousand euros, and the other for 15 thousand euros. What is the reason behind such a difference in price? Why isn't it a good idea to save money at the very beginning, but it's better to treat this purchase as an investment that'll pay off in the future?

A good company offers much more than just code writing

As we wrote earlier, a reliable software company has appropriate standards developed to prevent the release of low-quality code. These procedures include:

• Code review. Every piece of code written by a programmer is reviewed before release by at least one other developer. If they have any comments or find any errors, it won't be possible to release the code until all the comments are taken care of.
• QA (quality assurance). This is a team of testers who thoroughly check the stability and security of the application. Such tests can take up to several days and show even the smallest errors.
• Automated tests. In addition to a separate team whose task is manual testing, there are also automated tests. Thanks to them, with a single command we're able to check whether the code we just wrote didn't accidentally break the application in a completely different, unexpected area (this happens quite often).
• Documentation - Good documentation allows us to quickly introduce new programmers to the project and understand how individual components of the application work. This may seem trivial, but the lack of documentation is a real problem, especially in the case of large systems.

Application maintenance and development

Let's keep in mind that technology is developing very fast. The code of our application should also develop along with it. Even if at the beginning we have a great application with high quality code, after a few years it may turn out that it's no longer worth anything. A good software company carries out updates on an ongoing basis and adapts the code to current trends and technologies. A website that looked super modern five years ago, but lacked ongoing development, today will look outdated and not up to modern standards.

Quality of code - summary

Code quality directly translates into the quality of software operation. None of us would want to use an application that crashes all the time, is slow, and contains errors. Unfortunately, the price goes hand in hand with the quality. However, let's keep in mind that the more money we invest at the beginning, the lower the costs we'll incur in the future.

At Droptica, we'll create a Drupal website or web application for you, in accordance with specific coding standards. The quality of the code will be regularly checked by developers, testers, and automated tests.