What Does Quality Development Mean? Top 29 Rules

• Software Quality: Key Things to Know
• Software Quality Rules
• Conclusions

When people talk about software development, they often focus on the functionality and usability of a product, and it is often assumed that any software released by a contractor and accepted by a customer is bound to be of high quality. But that outcome isn’t actually guaranteed without rigorous quality assurance approaches, and IT companies must work continuously and establish a holistic quality management system in order to reliably meet user expectations. This article discusses the common approaches and rules that directly affect the quality of code in particular, and software development in general.

When planning to work with a company on a web development project, it helps to recall successful and unsuccessful examples you may have encountered previously. Everyone likely knows of websites which were based on seemingly promising business ideas, but which never reached their potential due to numerous unfixed bugs, permanent crashes, frequent hacks, poor productivity, etc. And those are just the issues which end up becoming visible. If you look deeper into the workflow of a web project, you will also hear about more structural issues, perhaps regarding the complexities and heavy cost burden associated with scaling a project, or the impossibility of transferring development and maintenance work from one contractor to another. 

Most often, such shortcomings in web development processes are the result of companies not following the rules and principles for quality software development that we will outline in this article. We are convinced that by following our recommendations, you can help ensure that the quality of your website or application meets your expectations.

Software Quality: Key Things to Know

It should be noted that most of the established quality standards relating to the management of a company as a whole cannot be applied to specific software products.

Let’s take, for example, the well-known concept of Capability Maturity Model Integration (CMMI). Whilst implementing the CMMI for Development model, aimed specifically at software development companies, will certainly contribute to a high quality level of development, this model will only enable an assessment of the maturity of the development company’s processes, and, crucially, not the outcomes associated with a specific product development project.

The same can be said for the ISO standards system. The ISO 9000 family of quality management systems standards (QMS) helps companies meet broad customer and stakeholder needs, although the quality of computer programs in more general terms, of course, can be counted among such needs. There are also special ISO standards devoted to assessing adherence to the general principles of quality of software itself. An example of such a standard was ISO/IEC 9126 Software engineering — Product quality adopted back in 1991 which defined 6 fundamental characteristics of software quality. It was later replaced by the current ISO/IEC 25010:2011 «Systems and software engineering — Systems and software Quality Requirements and Evaluation (SQuaRE) — System and software quality models». This standard offers 8 quality characteristics, but goes further in adding 31 sub-characteristics to make for a more comprehensive framework.

Although it should be understood that the above models offer a kind of foundation on which companies can build development quality management systems, none of them should be thought of as a universal tool for measuring the quality of an individual written computer program.

Having a clear set of parameters in place is essential when assessing an individual project’s quality. Remember that individual programmers will always evaluate the quality of code in their own subjective way according to their own experience and interpretation, so good practice is required in order to establish an accepted standard. Ultimately, on each project the quality of programming depends on factors such as the level of seniority of the specialists involved, the rules adopted specifically within the company, and the effectiveness of approaches taken towards project management. One essential fundamental in that regard would be to clearly and correctly establish project priorities. For instance, quality will suffer when a high pace of development is prioritized in order to launch a website or application as soon as possible. 

Furthermore, external and internal quality characteristics should be separated out. The external quality of a software product reflects how well it fulfills its functional requirements in practice, whereas internal quality refers to how the code has actually been written. 

In order to avoid excessive subjectivity in any quality assessment, one should strive for a quantitative expression and measurement of quality parameters. This is done using attributes, i.e. the measured characteristics of the software, and metrics, i.e. measurement standards. Therefore, by correctly selecting and using attributes and metrics, companies, project teams, and stakeholders are able to form custom software quality assessment systems which work for them. 

Often, during the initial stage of a project, the quality of development is not afforded sufficient attention. As a result, the resulting software product may then be very expensive to maintain or extend further. Relying on simple and cheap solutions at the start can therefore turn into significant losses in the future. For any serious long-term project, it is worth laying a solid foundation for ongoing development rather than in effect committing to rewriting code later or incurring high maintenance costs. This can be especially frustrating when a portal or application that has successfully “shot” and becomes popular stalls. 

Therefore, the approach to quality assurance must be balanced, and internal quality parameters should not lag behind external quality parameters. Remember that where internal quality of the software is high, it is possible, among other things, to facilitate bug fixing, reduce the cost of maintaining the code, and increase adaptability. The latter is especially important for Agile projects, with their changing requirements and the need to respond quickly to them.

Quality issues are not uncommon, as the State of Software Quality/Code Review 2021 report prepared by SmartBear demonstrates. The survey found that, in 2021, 11% of professionals surveyed were not satisfied with the overall quality of the software that their teams develop, whereas 26% took a neutral position on the same issue. More than a third of developers therefore cannot boast that they are satisfied with the quality of their work. Furthermore, it can be safely assumed that if the survey had been conducted among customers and users instead of developers, then the reviews would have been even more critical. This eloquently indicates that the issue of software quality remains hugely relevant, and so providing a definition of the rules and principles of best practice in this area is essential.

Software Quality Rules

In this section of the article, we will share our software quality assurance tips. The advice we outline here has developed organically from amongst the professional community of developers based on reflective analyses of their practice, and from our own observations, most senior specialists are guided by these rules and principles. At SECL Group, we are assured of the value of these recommendations based on our more than fifteen years of experience in web development.

In our view, a baseline universal approach in assuring quality is to manage the project on the assumption that it could be immediately and successfully transferred to the customer or another developer at any time. The importance of this approach is also nicely framed by considering the well-known metric called the Bus, or Truck, factor.

Referring to situations where information and capabilities critical to a project are concentrated on a few key members of the project team, the bus factor considers what happens in the event that these people are lost — i.e. if they are “hit by a bus/truck”. Without adequate countermeasures in place, then the further continuation of the project is placed in serious jeopardy since access to some part of the work or critical information is lost.

Therefore, any project should be conducted in such a way that any and all members of the team are deemed replaceable. If someone leaves the project then the results of their work and the valuable information they possess should not be lost, but remain available. We’ll consider later how you might assure that this is put into effect.

This approach is similar to another concept familiar in the business environment, which says that any business must be created for sale. In other words, even where an entrepreneur does not plan to sell their business, they still need to build their structures and processes correctly, and always keep documents in order with the mindset that they might. It is always useful to conduct business in such a systematic and structured way, and it is the same with development: ensure that your work is easily transferable to newcomers.

It is always preferable for customers to cooperate with contractors who do not leave their problem-solving for later, and which do not allow gaps to form in any development component. Therefore, we recommend that you always learn about the methods of ensuring quality of development that the company you entrust your project to use.

Below we outline 29 software quality rules and principles which can be used as a checklist to test the maturity of the team or company that will develop software for you. We highly recommend sticking to the following:

1. Standards. Let there be no single document regulating all development components, but adhere to generally recognized Coding Conventions, MDN Web Docs, and Naming Conventions applicable to all programming areas. Ensure that standards for programming languages, frameworks, and/or platforms have also been adopted. 

Among them are: 

     Python: PEP 8

     JS/TS: ECMA, JavaScript Standard Style, Google TypeScript Style Guide, ESLint

     PHP: PSR

     С#: ReSharper

     HTML/CSS: W3C, etc. 

Of course, this list could be greatly expanded upon depending on the specialization under consideration.

2. Certification. It is worth paying attention to any relevant certifications from reputable organizations that verify skill levels in specific technologies or professional credentials. For example, for Project Managers (PMs), the generally accepted certification is PMP, and for Quality Assurance (QA), it’s ISTQB.
3. Project team experience. It is important that teams are made up, not just of seniors, but more pertinently of those who have relevant industry experience and a deep understanding of the specifics of the domain in which the project is being carried out. For example, developing medical applications requires a relevant approach and knowledge base, and the price of a mistake in this area could well be a human life.

In all large projects, there will of course be programmers of different levels of skill and experience; from juniors to seniors to CTOs (chief technology officers). Not all tasks within the project will necessarily need to involve senior developers exclusively, and besides, it is not always expedient in terms of project budget. Most important are the interactions that take place within the project team regarding code quality control, testing, mentoring, and knowledge sharing between colleagues.

4. Project management. The chosen methodology (for example, Scrum or Kanban) is not as important as the experience of the PM (project manager). Total seniority is measured in years, as well as in terms of experience in a specific industry and projects of a certain size. We believe that the level of PM is as decisive as the skill of your programmers because it is the PM who controls quality, deadlines, and processes.
5. Documentation. It is very common that large projects work with outdated or incomplete documentation. Of course, issues with documentation can be sorted out over time, but it is a time-consuming and inefficient process. It is better to ensure that there are always up-to-date documents covering general descriptions of the project, its tech stack, working environment and API, as well as requirements specifications, design/construction plans for system components, UML diagrams of system modules, algorithms, deployment instructions, user guides for the program, etc. 

Software documentation should cover not only essential technical characteristics and consumer qualities, but also information about the processes involved in its development, application, and maintenance. Quality code is usually accompanied by good, well-written documentation that conforms to accepted standards and style guides.

6. Architecture. For any serious project, its architecture is custom designed and the right technologies are selected to ideally suit it. If this is not done, then there may be negative consequences, including having to rewrite the project from scratch.
7. Allocation of separate servers for development and testing. Usually at least 3 servers are recommended: a dev server for developing a project, a test server for testing finished products, and a production server for tested code. Often, web development teams create another server that is similar in parameters to the prod server. Such a pre-prod server simulates the prod server, has real content and user databases, and helps to avoid errors on the prod server that should never be allowed to occur.
8. Proper server setup. Here we refer to maintaining the working environment of the project, monitoring the server, as well as keeping an eye on automation. It is advisable never to forget about the need to constantly update the software on servers. After all, it is aimed primarily at ensuring security.
9. Server productivity. Of course, today you can keep a project in the cloud, which can indefinitely expand the critical resources allocated to the project. However, the cost of using such resources also guarantees that you will pay more. Remember that in the relationship between server performance and the quality of coding, customization, and project optimization, good programming allows you to use fewer resources.
10. Security. This is a distinct area of knowledge, and if a programmer uses, for example, a popular framework, then, as a rule, there are already basic security features in place. Nevertheless, developers must have relevant knowledge to prevent hacking of their project. Particular care is required when using third-party solutions because it is often through them that hacking attempts are made. When it comes to web development, advice and tools from online communities like OWASP can also be very helpful. You should also always keep the security and protection of the server firmly in your mind. Experience tells us that some hacks happen due to code imperfections, and others due to insufficient server security.
11. Code cleanliness. Unnecessary and unused code accumulates during work, and any redundant code should be removed. This is often neglected and causes negative consequences such as sites or applications taking too long to load, requiring additional server capacity, and increasing the time it takes for new team members to onboard onto the project. Cleanliness is a classic sign of code quality.
12. Code structuring. The code should have a structure, divided into logical parts with understandable function names and so on. This will help everyone involved in its ongoing development.
13. Code readability. Code must be clear not only to its author. Therefore, indents, nesting, a single style, and similar details matter a great deal. Readability is largely achieved through code consistency. The more numerous the project team, the more important it is to ensure code consistency as every programmer has their own way of working. Specialists may name variables differently or determine where to put brackets in varying ways. Companies and development teams should establish uniform writing rules for projects. Otherwise, reviewing, fixing, or documenting code written by someone else takes an unnecessarily long time and becomes much too complicated.
14. Code concision. Once upon a time, programmers from South Asian countries were paid per number of lines of code or characters. Logically, they therefore multiplied it on purpose. To write the number 5, they could write a special formula: ((1+1)+(5-2))*1=5. This practice is no longer common, but you might easily comprehend the legacy issues caused by this approach. 

Any piece of code can be written in many different ways but it is always better to adhere to the “less is more” rule. Efficient, high-quality code is concise. Fortunately, many mechanisms have been developed to promote brevity. Recall at least the good old principles of KISS (Keep It Simple Stupid) or DRY (Don’t Repeat Yourself).

15. Code commenting. This allows you to understand exactly where the code you need at any given moment is, where it starts and ends, as well as which functions or formulas it has.
16. Code modularity. This is a useful modern trend. Recently it has become an extremely popular approach to design software architecture based on microservices; an approach which originates, quite simply, from modularity. Modular code is easy to split and maintain in the future, making rework fast and cheap, increasing service performance, lowering the entry threshold for new programmers and offering many other advantages.
17. Design Patterns. The wheel has long since been invented. For any standard situation, there are already going to be well-established patterns or best practices for development that you can depend on. You just need to know what they are and how to use them.
18. Optimization of additional technical tests and the testing system as a whole. Quality of code is confirmed by checking for errors or malfunctions. Therefore, in order for the software to be functional and practically applicable, one should be prepared, especially in large and non-standard projects, to apply other tests. 

For example, for e-commerce projects, A / B tests are often used, and in FinTech projects, additional attention is paid to security.bt. Often, when changing something in one part of the project, developers realize that it would be nice to fix other parts of it, but deem that this is not critical right now and can be done later. These deferred commitments gradually pile up and clog the project. A quality approach implies timely correction of deficiencies.

19. Refactoring. This refers to rewriting parts of the project with better quality, or targeted towards new goals. In doing so, technical debt can also be eliminated. Refactoring is not usually carried out because a programmer wrote code badly from the very beginning, but more typically because there is always something upon which to improve.
20. Repository. Creating such a storage location for software is standard practice. However, until now, some small projects or inexperienced programmers have not used them. But a repository is mandatory when more than one developer is working on a project, and for security reasons, both the contractor and the client should have access to it.
21. Backup. Did you know that even well-known hosting providers have fires? For example, a fire broke out in the data center of Europe’s largest cloud provider OVH in 2021. High-quality development should therefore include such “little things” as a proper backup to a backup server in another data center
22. Automatic analyzers. These are often used to check typos, basic rules, syntax, and the like. The first level of a development quality assurance system consists of these automatic analysis tools.
23. Unit tests. These are aimed at checking the correctness of working out existing code after project updates, so that the appearance of new code does not create problems for in-use working system elements.
24. Test Automation. The use of automated tests is especially important in large projects where they help to reduce testing time and therefore speed up development. Above all, such tests are very effective for interfaces.
25. Manual tests. These are indispensable for checking automated tests, as well as for detecting errors that are difficult or impossible to find with software tools.
26. Code review. Extreme programming (XP), a type of Agile software development, uses an interesting twist on this technique. Two programmers write code on the same computer, think over, and check it together. Of course, it is not always advisable to spend the time of two programmers at once in this way, but remember that even the code of a senior specialist still needs to be checked and reviewed by someone else. After the review has been conducted, each developer will have edits, it’s just that the junior will have a lot of them, and the senior less.

Conducting code reviews is a must, a point on which it seems everybody in the software development community agrees. In the aforementioned Code Review 2021 report, we learn that the practice of code review is very widespread, and that the form of their application is being constantly improved. The majority of those surveyed (54%) are satisfied with their current code review process, and there is a strong correlation between satisfaction with the code review process and satisfaction with the quality of released software.

27. Third-party integrations. Almost all modern software integrates with something. It is important to do this correctly, efficiently, and safely. Beforehand, a customer and contractor must make the right choices about this together, deciding in which cases integration is indispensable, and in which it will be easier to write product modules on their own.
28. CI/CD. CI/CD is understood as a combination of continuous integration (CI) and continuous delivery (CD). Sometimes the focus is on continuous deployment (CD) instead of delivery. With the improvement of DevOps practices, the CI/CD pipeline of software development, testing, integration, deployment, and monitoring has become continuous. Deployment automation saves the project team time and improves the quality of work. 
29. Maintenance. It is at this stage that the quality of software is clearly revealed. A truly high-quality code is understandable, easy to maintain, and provides the possibility for further refinement, reuse, and replication. Unstructured and confusing so-called “spaghetti code” not only complicates and increases costs associated with support, but also negatively affects the extensibility of a project, its speed of maintenance, and many other aspects of the functioning of the operating software far beyond the usual SLA. This item, although last on our list, needs to be conscientiously thought about from the very beginning of any project.

Remember that maintenance goes far beyond just providing customer support in specific technical details. Properly performed maintenance, which does not necessarily have to be associated with high costs, focuses on solving a client’s business problems, and ensures the stability of the system and its ability to expand.

Conclusions

In this article, you have learned about existing approaches to ensuring the quality of software development and associated code. Guided by our proposed rules and principles, you will be able to assess the reliability of a potential contractor and the quality of the software you receive from them. We suspect that it is highly likely that you agree that it is beneficial for customers to invest in quality software that is properly updated, scaled, and maintained.

At SECL Group, we have implemented many projects with a committed focus on the quality of web development. The founders of our company have an established technical background and have been working in the software market for decades. If you are not sure about the quality of your project or have encountered significant difficulties in its implementation, please сontact us. We stand ready to advise you and lay out your options for solving even the most complex of problems.