In 1996, Ariane 5, Europe’s latest unmanned satellite-launching rocket re-used software from its predecessor. Unfortunately, the rocket’s engines exploited a bug which was not discovered in previous models. Thirty-six seconds after blast-off the rocket’s engineers hit the self destruct button following multiple computer failures. The resulting overflow conditions crashed both the primary and backup computers (which were both running the exact same software). The Ariane 5 had cost nearly $8 billion to produce, and was carrying a $500 million satellite payload when it exploded. As you can see, defective software due to poor code quality can result in tremendous losses or even business failure.
Why does code quality matter?
Business leaders often consider code quality as an abstract element that doesn’t directly affect results and revenue. However, that is not true. In reality, bad coding practices undermine product performance (leading to crashes or poor responsiveness), which in turn typically leads to downward trends in user acquisition, retention, and engagement. At the same time, cutting corners may actually increase the development costs in the long term, as project maintenance requirements go up. In the long run, poor quality code can easily influence a business’ revenue, even though everything looks fine from the perspective of an end-user. Moreover, bad programming practices result in security vulnerabilities, opening up the software to attacks from outside sources.
Red flags
How can you identify that things are going wrong? Below we suggest a list of signs you should pay attention to and criteria that might be a matter of concern.
Maintainability
One of the most frequent causes of pain when working with other people’s code (or your own old code if you’ve not been following best practices) is that they didn’t consider the future need for their code to undergo changes and extensions. Here are a couple of warning signs that a given codebase might be difficult to maintain in future:
- It is strongly integrated with another system
- Configuration is hard-coded
- It racks up a technical debt by increasing investment in a technology which the team wants to phase out (e.g. utilizing functionality from an old library version)
- It relies on old code which has been planned for replacement or removal
Security vulnerabilities
Sometimes, when they’re forced to work fast, developers might not consider all the security implications of their work. It can lead to the creation of insecure code that introduces vulnerabilities into the system or exploits tools or libraries which are out-of-date or have known problems. Software that is inconsistent or contains bugs and errors in logic may be susceptible to attacks from outside sources.
Readability
In terms of software, readability means that the code is easy to understand. It involves the ability to easily see the code’s inputs and outputs, what each code line does, and how it fits into the overall picture. The most common code issue is that it’s not broken up into small enough chunks, so the structure is too complex and difficult to comprehend. Another aspect of readability is the naming of classes, functions etc. Good descriptive names save everyone’s time and reduce cognitive load when reading code. You might be surprised if you compare project development time with and without these practices.
Reliability
Reliable code is failure tolerant. Reliable code takes into consideration that sometimes things will fail, but protects the user experience from feeling any adverse impact of such failures. No one is safe from assets not loading, database records being missing or API requests returning errors. Yet, if these issues regularly turn into user complaints or the software not working, this is a dangerous signal of significant underlying code problems.
Scalability
Server-level scalability has to do with unexpected load. For instance, a website’s homepage might go viral and be hit with dozens of requests per second. A user with thousands of activities in an app might decide to check their full activity log. Or a product will run a high visibility ad which leads to 100 people trying to buy it at the same time. If the software is not designed to handle very high usage periods, it might fail catastrophically when these pressure points appear.
Another aspect is code-level scalability. Scalable code is flexible to adaptation when new requirements arise. The less changes need to be made, the more scalable the code is. By way of an example, for one of our enterprise clients we developed two basic Drupal 8 themes. From now on, engineers will require minimal time to create new child themes for this project as they won’t need to develop them from scratch.
No project documentation
When one team passes a project to another, the absence of supporting documentation along with the code is always a warning sign. A good readme usually explains why the project exists and how to use it. If the previous development team doesn’t provide any documentation, it means the project was initially run with a distinctly flawed approach. Most likely the code architecture and “the big picture” will be missing, which can easily result in project failure. Even if you don’t plan to change vendor or development team, you should still produce documentation to simplify the onboarding process for new in-house developers. If your development team is big enough, you might expect a 13% staff turnover rate (the average for IT teams according to LinkedIn). With good documentation available, a new developer joining the project could have an onboarding process of a couple of days rather than a week or two, with significant knock on reduction to your development cost.
Performance
Performance should be considered in two dimensions: performance for users and resource optimization for the team. Lengthy database queries or multiple API requests make code perform slowly for the end user, degrading their experience. Getting an effective server setup to handle the loads you’re dealing with is essential. On the other hand, if you commission cloud servers which are a lot more powerful than your needs, you can end up wasting resources.
Factors influencing code quality
Several factors that might contribute to code quality:
Technology
Usage of obsolete frameworks or libraries can result in bad practices and potential software problems. For example, on one website, we developed a WordPress theme that loaded unnecessary libraries and caused the website to run slowly. Once we converted it to HTML, everything started working significantly faster.
Choosing the wrong tech stack for a project can also be dangerous. If you start out with an inappropriate tech stack, you might discover partway through the project that you need to make some major changes to your existing work, or even to start over completely! This is why we believe a discovery phase to be an integral part of the project. It helps to clearly identify what features will be developed, what technology will be the best fit and how to maximize your business success.
Development environment
Creating a proper development environment and establishing development processes encourages developers to comply with coding best practices and better co-operate on code changes, which results in better code quality. For instance, architecture that is a bad fit for the software requirements’ particular functionality can result in bugs and difficulties maintaining the code. Sometimes unexpected issues occur when a developer doesn’t test the software manually before pushing it live. The staging environment makes a big difference. The stage server should be correctly set up, or else unexpected errors might occur at the wrong time.
Project management
A project manager is the one who is responsible for identifying precise project requirements and discussing expectations with the client. They deliver a clear vision of the project and its deliverables to the developers whose job is to write code that delivers the required functionality. Blurry or confusing requirements cause vague project specifications which can impede the developer’s work and degrade code quality.
It’s up to the project manager to select the most suitable development methodologies and best practices to run the project efficiently. In fact, management as a vital part of a successful project is a broad topic that deserves a separate blog post.
Project deadlines
Another factor that influences code quality is unrealistic project deadlines. The pressure to finish the project within a specified, unrealistic timeline or budget is likely to force a developer to create software that is far from ideal and implement functionality without appropriate testing. The same problem might also arise if a project manager didn’t leave enough refactoring time while planning a project.
Scope creep
Scope creep also has the potential to wreak havoc on project boundaries. Scope creep implies adding new features or requirements that widen the scope of work, after the project has launched. In this case, code quality suffers while developers and managers don’t have enough time to develop functionality not outlined in the initial project scope. Moreover, it might turn out that the tech stack selected on a project on the basis of its initial scope doesn’t fit this additional functionality. As a result, developers might need to rewrite some already completed parts of a project.
Patterns mismatch
Established code bases usually contain patterns in naming conventions, decomposition of program logic, data type definitions etc. for internal consistency. When adding new code to a codebase, developers should check if it meets those patterns already established by the team. New code which diverges from existing standards without a valid reason is bad engineering practice, leading to confusion.
Action points to protect your business from losing control over code quality
Software development is a complex mechanism with many elements. Of course, you can’t supervise everything. But what you can do to protect your project is to educate your team to follow the best practices and patterns, to minimize risks and maximize profit. Below you’ll find some practical ideas on how to make code quality work for your business success.
Code review and mentoring by team leads
Code review is a widely adopted engineering practice at all big tech companies including Microsoft, Google, IBM and others. The results of a survey run within Microsoft demonstrate that developers consider code quality improvement, bug detection and knowledge transfer to be the main benefits of code reviews. Moreover, at Microsoft, the data shows that 3 out of 4 developers perform code reviews at least once a day.
Solid development companies have well-organized checks and monitoring systems to achieve a high level of code quality. At Ekreative we follow the industry’s best practices, so our team leads carry out code reviews on a regular basis. On top of that, if several developers on the same platform work on one project, they review each others’ merge requests. This additional code review is helpful to find bugs and ensure code quality. Before you start co-operating with a software vendor, clarify if they have any internal procedures for code review (supervised by colleagues and management). If not, find professionals who will be responsible for reviewing code within a team. The investment of time in reviews on a regular basis will pay off with high standards of software development and clearly structured processes within the company.
Zoom Out to See the Big Picture
One of the risks with code reviews is that they draw attention to code details rather than the bigger picture. That is why it is vital to run regular health checks of software, especially before releasing a big feature. In this way, supervisors will detect global issues like poor architecture, brittle or inefficient code and provide developers with valuable feedback.
Regular syncs to stay tuned
Сode may work, but does it work the way the Project Manager, CEO or user expects? Before developers put code in production, they should make sure that it provides the functionality it was intended to perform. Regular syncs with the team during project execution are vital to keep tabs on a situation throughout the development process. Besides, your project team should have defined quality assurance procedures to confirm new functionality.
Test Coverage and Test Quality
The presence of unit tests is critically important for robust software performance. But, flawed tests are more dangerous than the absence of tests. Ensure that the developers’ tests are maintainable, readable, perform properly, and follow the project’s established patterns. When it’s time to maintain or update existing code, developers should consider adjusting the tests as the first order of priority.
Adding and reviewing tests regularly improves code quality, helps to detect bugs in the early stages and eliminates human error. From our experience, unit tests can save up to 90% of the time developers spend on testing their code and fixing bugs. For example, before introducing unit tests on one of our projects, developers spent 8-12 hours a month on manual testing and even more than that on fixing issues and retesting. With unit tests, it now takes only 5 minutes to check the code before an update.
Keep future use-cases in mind
Encourage the team to make sure they keep future use-cases in mind while writing the code. For instance, when developing a marketplace product that is quickly expanding its product range, they should make sure that the code can be easily updated to support new types of product in the future. At the same time, developers sometimes go to extremes trying to future-proof their software so much that they add support for potential extra features that are extremely unlikely to ever be part of the project. Finding balance between these two moments is essential for setting yourselves up for future success, while not wasting excessive time on the current build!
One last, practical step that’s effective and doesn’t require any effort on your side – is simply contacting your vendor/development team and asking how they evaluate the state of your project. If you partner with a dedicated team, most likely you’ll hear some valuable insights. It’s a good practice to discuss this question with regular frequency in a team’s retrospective sessions. Remember that consistency and system control is key to your software business success.
If you’re not in a position to run the code quality best practices described above yourself, or you’re simply looking for an external review of the code quality on your current project, don’t hesitate to get in touch with our expert team or book a free code assessment session.