Code Quality: Its Importance in Custom Software Development
The quality of an application or software is often attributed to an intuitive user interface, thorough testing, and security. But I think the main aspect of reliable custom software is code quality, which is often neglected. This led me to ask a question that how the code quality can be maintained throughout the software? If that can be done, what are the parameters to measure the software code quality?
Well, we shall explore these answers in a while. But, you should know that bad code quality can create issues in the software; sometimes hampering the other enhancements that the client would like to make in the software.
Let me explain to you using an example. Suppose you own an application that is working really well. Now you want to enhance the user experience of your app by adding features to your existing application. You approach an agency of developers or freelancers for that purpose. When they observed the code of your application, they reported that the code can’t be refactored, citing the code is written in an improper way. If you still go ahead with the feature enhancement in the same code, it will further create issues in your existing software application. Eventually, you have to either make changes in the plan of feature enhancement to your application or start the development of the application from scratch. The third option, which most of you would not like to opt, could be to let the application be running as it is and not to disturb the code.
Many organizations rightly don’t care about code quality. Their businesses will keep making money, whether code is good or code is bad.
The problem of poor code will never catch up to them… until it’s too late.
And, by then, everyone important will have found a new job anyway.
— James Powell (@dontusethiscode) August 31, 2019
You might be wondering if this could be the scenario, what would you have done? For that, let us understand code quality and its importance.
Code quality refers to the usefulness and maintainability of the code in the long term. It covers both good and bad quality code. It basically provides insights to the project managers about the coding practices and style followed by a team of developers. This quality – good or bad – is all subjective. Different teams might use different definitions based on the context. For a firmware developer, it might mean a different thing while it might be something different for a web application developer.
Code quality is very important for the successful implementation of any program. It is the most important KPI to measure the usefulness and efficacy of the software project. But, maintaining the quality of code is not that easy because it requires consistency in efforts with a focused mindset of the software development team to meet the quality goals. This is very important for a software project but the developers are often seen side-stepping the quality when they are required to complete their tasks in a very short span of time.
Writing code should be considered as an essential investment on which return will follow almost immediately. For this, the code should be readable, consistent and documented which would be easier to review, leading to lower development efforts. A well-designed software that is equally less complex would be more robust and can be tested easily. In other words, high code quality can be one of the best ways to lower the technical debt.
When a developer fails to heed the code quality, it can sometimes lead to additional rework in the code. This can eventually enhance the cost of the software.
Let me explain to you with the help of an example.
Suppose your developer has written some code and it is a simple program. But the method is written in such a manner that other developers need to spend some time in understanding the code.
In the above code snippet no apparent coding standard is followed (seen, for instance, usage of curly braces and empty lines).
Further, a whole chunk of dead code is there in the program which defines poor readability of code.
The low-quality code is more prone to errors/bugs and difficult to test properly.
Code Quality is important as shared in the experience by Alex Golec, who was working with Google, now Engineering Manager at Reddit.
While working with Google, we aggressively pushed code quality. Nobody can submit code without someone else reviewing it. Also, you cannot submit code in the language in which you aren’t certified as proficient without someone with proficiency (called readability) reviewing it. We have an entire team that is dedicated to performing modernizing refactors across our entire codebase to remove deprecated methods, migrating to new language features, etc. Unit testing is not strictly enforced, but we have automated dashboards that will show you your coverage and guilt you if it’s poor. The result of all this is that even if a team wants to just get things done, they’re going to be nudged in the direction of better quality simply by using our tools.
Talking about my team, we work in Ads. We are a group of just over half a dozen people operating a handful of revenue-critical systems, and our code quality standards are raised accordingly. We put a lot of effort into getting the code right at the outset and then running it for years without the need for massive intervention. These involve a few things. First, if we require an extra half a quarter to make a product happen right, then we take it. Secondly, we write thorough design documents before breaking the ground. Finally, we spend a lot of time refactoring and cleaning things up. Sometimes, it is more cost-effective to clean house and make otherwise changes simple.”
Measuring code quality is a tough task. This is because it is really hard to define the right quality of code. For instance, many people would say that the code has to function correctly most of the time but think about it, is it really possible? It would be like showing the customers exactly what they want. But, the real fact is that finding the initials of given user names is also tricky when it comes to writing the code.
Some people define and apply various metrics to the code and there are tools to report many of these metrics. For instance, the count of open reported defects in a given product, defect density (the number of defects found per number of source lines of code of product), fan-in & fan-out (number of modules that a given module calls & number of modules that call the module), coupling (number of inputs, outputs, global variables used, modules), cyclomatic complexity (number of paths through a given block of code), Halstead complexity measure (program vocabulary, program length, calculated program length, etc.), count of open static and dynamic analysis findings, etc.
Well, sometimes the best measure of code quality is to take a qualitative approach i.e. asking someone to look at the code and comment on it. It can be much easier when we follow some consistent rules or have a style guide for writing the code (from formatting to naming conventions). Ask someone about the readability or maintainability of code, it will help you better in knowing the quality of your code.
The only metric I care about today about code quality: how hard is it to fix something that doesn’t work as expected without breaking other things.
— Oleg (@oleg008) October 3, 2019
Good code quality is important for software as its absence could sometimes lead to financial loss or a waste of time. These finances or time could otherwise be used for maintenance, modifications or adjustments if code quality is not that good.
The efficiency of the code is directly related to the performance and speed of the software, whereby the quality can be evaluated on its basis.
As a known fact, nobody would like to use software that takes too long to perform some action. In order to enhance the efficiency of the code, one has to remove the unnecessary or redundant code. Further, try to write reusable code, reduction of resource consumption, use of appropriate data types, functions and looping at an appropriate place, etc.
It refers to the ability of the software code to perform consistent and failure-free operations every time it runs. This is an important aspect of code quality to be good. This is because if the code functions differently every time it runs with the same input in the same environment; and if it breaks down often without throwing any errors, the software would be useless. A code can be made reliable by reviewing and testing it thoroughly in all the possible ways; by using proper error and exception handling, etc.
The robustness of the code is its ability to deal with the errors while the program is being executed, even under unusual conditions. This is an essential part of the code quality of the software. For instance, in critical software such as in spacecraft, dead code and more generally untested code is forbidden: If a cosmic ray produces a single-event upset(SEU) that in turn makes your dead code being activated, anything is possible. If the SEU activates a portion of robust code, the (unexpected) behavior stays under control.
A robust code is easy to change as the external factors don’t affect its behavior. The more the code is robust, the less are the combinations that can cause a bug in the code. It is predictable, therefore, easy to integrate and it is consistent.
“Robust code works fine no matter who, when or how it gets called”.
Robustness of the software can be achieved by testing the software in every condition – usual and unusual, using proper error and exception handling, allowing the user to be able to debug the program in an easy manner by providing clear and understandable error messages, etc.
This is the ability of the code to be able to run on as many machines and operating systems as possible. This holds importance in the code quality to be good as it would be wastage of both time and energy for programmers to write the same code again when there is a change of machine or environment.
But there are several ways you can ensure a portable code. It’s important to regularly test code on different platforms, rather than waiting until the end of development. It’s also a good idea to set your compiler warning levels as high as possible — and use at least two compilers. Enforcing a coding standard also helps with portability.
This refers to the addition of new features, modification in the existing ones or fixing the bugs with minimum efforts. Also, taking care that it does not affect the other modules that are related to it. This is an essential part of code quality as the software quite often requires new feature enhancement or bug fixes. The written code should be easy to understand, easy to modify and find things that need to be changed.
Also, you should check that the changes done should not introduce any bugs in the existing code functionality. This is easy to achieve using proper naming of variables, method and class names, proper indentation and formatting styles, good technical documentation and writing appropriate comment or summary descriptions at the top of files, classes or functions.
The code should be readable in a way that it should be easily understood by any new person reading it or someone who has not seen it in a while. It is very important that the code written by one person should be understood by everyone else.
For the code that is badly written, it becomes really hard to understand what the code does and the place where the changes are to be made. This could waste a lot of time trying to figure out how it all fits together before taking any action.
Sometimes, it could even end up in writing the code again, assuming that it is buggy and carelessly written. In order to make the code more readable, use proper names for variables, methods and classes, consistent indentation and formatting styles should be practiced with writing appropriate comments or summary descriptions at the top of files, classes or functions.
For an organization, it is very essential to maintain a good quality of code. Rather than working on the quality after completion of the code, you should emphasize on quality from the very beginning of the project.
Don’t spend more time on code quality. The real power move is growing the skills and habits that give you quality in the same timeframe.
Quality is not an act, it is a habit.
Don’t spend more time on code quality. The real powermove is growing the skills and habits that give you quality in the same timeframe.
— Mathias Verraes (@mathiasverraes) October 29, 2019
There are instances where you will find that while writing the code, if we take care of the quality from the start of the project, then the overhead of improvising the quality is considerably reduced. Listing a few points for maintaining the quality.
Structure of the system
One of the most essential aspects of coding is its architecture and structure. Developers are required to know about the universal design patterns that are quite popularly known to the most and therefore, can be easily understood by the other members of the team. With the use of proper principles, the code can be easily extended in the future. The developers need to have a clear vision of how the whole project will look like after the completion so that it becomes easy for them to create the draft and the blueprints. Like in a building you won’t build a couple of first floors to get an idea that you would be able to build the next 100 floors or not. In the same manner, you would like to divide all the functionalities into modules so that one feature is precisely in one place – easy to find and if needed can be changed or fixed in one place only. (This is termed as separation of concerns).
Further, mixing different things all over the code becomes all the messier and really hard to be understood by someone else reading the code, sometimes harder even for the developer who has written the code in the first place. There should be lesser dependencies while exchanging of modules and components. Say for example, if at some point we would require to upgrade our database to something faster.
A codebase can be made more readable and easier to understand by simply taking care of small things like naming conventions, file structure, variable names, etc.
It is seen that developers change from time to time, and if onboarding would take a couple of weeks or months, it might have an adverse effect on the business. Also, it is recommended to use the same terminologies for the modules and classes as used in the documents and everyday discussions so that confusion and misunderstandings can be avoided.
With 90 or almost 100% test coverage, sometimes it is not possible to cover all the possible cases and errors. This affects the quality of the product. As the software is continuously evolving, therefore, at the time of changing something we don’t wish to break something else at the same time (regression bugs).
If the high code coverage is a KPI in some companies, it is not necessary to have the same requirement in your company too. If you do, it would result in a bunch of useless scenarios and not testing the units that are supposed to be tested. Also, a lot of time would be wasted in writing those along with enhancing developers’ frustration.
Further, it is required for you to understand the value of creating those test coverage in the first place. For a very good product development process – education, trust, and good communication are the keys, which means better cooperation with more experienced developers.
There are certain best practices that could be followed for improving the code quality.
Optimization & readability
Write the code which is simple and could be easily understood by the developers as time and resources involved in the hard readable code will be much higher than that being gained from optimization. If you require to make optimization, then make it like an independent module with DI, 100%test coverage and which will not be touched for at least a year.
Architecture at priority
Many people say that they do things really fast as they don’t have time to think about architecture. But 99% of them got into big trouble because of such thinking. Writing code without thinking of the architecture is in vain. Before the start, you should understand what your code will be doing, what are the uses, how modules and services work with each other, what structure will it have, how will it be tested and debugged, how will it be updated, etc.
It can be as good as it can be bad.
A code review can be organized only if the developer reviewing the code can understand 95% of the code and is able to monitor all the updates without wasting much of the time. In all other situations, it will just be a time-consuming task and everyone will hate it.
Sometimes, people think that code review is a good way to teach new teammates who work on different parts of the code. But they forgot that the main objective of code review is maintaining code quality and not teaching. Let’s suppose that your team is working on code to control the cooling system of the nuclear reactor. You made a severe mistake in the logic and then you gave this code to be reviewed by a new teammate. How do you think would be the risk of an accident? I can say that it would be more than 70%.
It would be a good team in which the team members have their individual set of tasks and they are responsible for the exact piece of work. If a person wants to learn something, then he may go to the person responsible for it and can ask him/her.
Code review is important for both maintaining the code quality and the growth of the team. The code should be reviewed early and often in small chunks. Let us see what Matt Engledowl has to say about code review,
“The purpose of code review should not only be restrained to ensuring good code but also helping the team to grow together. It should be a practice to get the code reviewed early, often and in small chunks. It is toiling to review a 1000 line code which would be spanning several sub-systems. Well, this is the quickest way to get people either blindly approve or to discourage them from taking the time to review. Smaller changes make it easier to justify taking a few minutes to look at the code and make some constructive suggestions. Further, it makes easy for the person writing the code to implement the suggestions.”
Maintaining a good quality code is as important as writing the code. The quality of code can be measured by using tools or seeking review by someone experienced. Well, bad quality of code can be improvised at any time. Further, with the implementation of DevOps in software development, the overall code quality and the process of maintaining it has been improved. We, at Simform, have skilled professionals who take the utmost care of maintaining the quality of the code while developing software. This helps us in serving our customers in the best possible manner.
If you have anything good to share on code quality, then your views are most welcome in the comments below.