There are many factors that impact negatively software code quality:
- lack of awarness of complexity
Complexity has a major negative impact on software quality. Programmers see and feel this complexity, but are not fully aware that it is growing incredibly fast and where it comes from
- lack of knowledge
Many programmers do not know where complexity comes from. Programmers are taught how to write code, not how to build and design solutions. This is the biggest problem. Solutions must be designed and modelled to be simple, clear and extensible. This requires appropriate knowledge and experience
- no solution adaptation in development cycle
Why does the code of some solutions look like a mess? Because new requirements are constantly being incorporated into the product/solution without adaptation (redesign, refactoring), thus creating a lot of dependencies and mess.
- lack of awarness of management/companies/business
Maintaining and implementing new features in complex solutions takes, I believe, up to 10 times longer than in high-quality solutions. There is a huge difference in terms of time, people satisfaction, and business money. One large company I worked for realised this, I think because of the huge maintenance costs, and decided to rewrite old applications
- no quality culture
Companies need to understand that to achieve quality, there needs to be a culture of quality – awareness building, relevant initiatives, events, and so on. Quality is not something that just happens, but is the result of hard work and culture
- no quality IT standards
The IT product/solution is complex, therefore the quality of the product/solution is complex. In fact, in IT, quality is not defined. There are no standards and no clear indicators
- business do not pay for quality
Business pays for working code/functions, not for working code of high quality. Pity. But as mentioned before, quality standards are not defined, so business would not even know what they should pay for. But as everyone knows: where there is money and need, anything can be done
- employing not experienced developers
Quality requires knowledge, experience and skills. Junior/mid-level and even senior (with two years in IT) developers can write code and a working solution. However, they do not have enough experience and skills to implement high-quality solutions
- no time – business pressure
I worked on a project where the business and management pressure was high. There was no time to design/redesign the system and processes. As a result, the complexity of the solution increased dramatically, causing many problems, errors, lack of understanding and staff turnover
- optimistic estimations
During planning, task/user stories are estimated quite optimistically. This is because people do not have a deep knowledge of implementation complexity. For example, if a task is estimated to be 5, and then during analysis and implementation it turns out that there is a need for some code/process optimization and refactoring, which increases the complexity of the task to, say, 8, there is no time to get the task right
- it is too late/big technical debt
For some products under development, complexity is already so high that it is too late. Too late because small improvements take a lot of time, the return on investment is very low, so nobody is interested in improvements
- employment and project unstability
No one is going to put lot of effort, and unpaid overtime to achieve high quality knowing or feeling that participation in this project can soon end
- code review is enough
Code review is a common practice in many organisations. Companies believe that this process is sufficient to achieve code quality. No, code reviewers mostly check the low-level code, but it is not possible to check everything in detail. It is also difficult to check the solution design because the reviewers do not know all the requirements and specific problems
- sonar is enough
No one tools makes the solution good. Of course, tools helps, but IT software is so complex that only people can do it properly. Especially the design which requires analysis and modelling
- poor communication
I think it’s obvious that poor communication, or lack of communication, is a source of misunderstanding and improper design and implementation of features
- rapid requirements change
Requirements can change very often, but software/systems do not. The software tries to keep up with the requirements by creating shortcuts, workarounds, etc., which leads to a significant drop in quality
- no documentation
The code read by programmers answers the question of what the system does. However, it does not answer the question of why the system does what it does. Lack of documentation such as ADRs (the most important decisions in a project with justification), processes/flows and requirements leads to many questions, wrong decisions and errors
As you can see, there are many factors that negatively affect the quality of software code, but how to deal with them, how to avoid them? That is another story.