Evolution of Architecture-1-What is Technical Debt?

It is a session in software architectures trainings where we discuss the good and bad experiences in our previous projects. I guess we are never satisfied with the software we develop as engineers. The phrase I heard the most in this session was: “If I were to decide, I would rewrite this software”.
They will state that they do not know the field of business sufficiently at the beginning of the project and that they realize that some of the design decisions they made at the beginning of the project are not the ideal decision afterwards. He/she stated that they focused primarily on functional features, but in the advanced stages of the project, the software did not work consistently and they lost a lot of time in detecting and resolving errors. When we say let’s reuse the developed component in the next project, they will state that this will also put the new project into difficulty, and best of all, it should be rewritten with what has been learned from this project. They will even argue that it is better to develop the relevant module with the latest and most fashionable technology or programming language.
The non-ideal code, design or architecture, the shortcut you use to solve a problem, or the errors or operational situations that we do not consider, will be detected and corrected in the code afterwards. This situation, inspired by the financial system, is described as Technical Debt, because bringing a feature that is not done on time to the system later will require a payment with interest, which will be more than the initial cost. Technical debts can be created unconsciously as well as consciously. Refactoring is the best-known method of reducing technical debt.
The concept of Technical Debts is seen as 5 main classes:
Code Technical Debt: Failure to comply with the coding standard and incompatibilities found by static code analysis tools fall into this category.
Design/Architectural Technical Debt: Wrong architectural design, non-compliance with design decisions
Testing Technical Debt: Insufficient testing, insufficient test coverage, and poor test environment
Documentation Technical Debt: The design and design decisions are not documented sufficiently and the existing documentation is not compatible with the software,
Business Area Technical Debt: Insufficient experience gained and insufficient analysis in the business area where we develop software.

Software bugs are not considered technical debt as a philosophy. These software bugs are visible to the user. Technical debts are problems that are not visible to users, but when they want to change/improve the product.

How Is Technical Debt Created?

Lack of Analysis: The fact that the work to be done at the beginning of the project is not well defined, the needs of the stakeholders are incompletely analyzed, the team whose software will be developed does not know the business area (domain) sufficiently, which emerges as technical debt due to incomplete analysis.
Incorrect or Outdated Technology: Technologies in software are developing very rapidly and expectations are increasing. The use of old technologies may prevent the product from providing customer satisfaction and the development of the software with new features. On the other hand, using a lot of new technologies in the same project just because of fashion will create problems such as the installation, definition, effective use of these technologies, and their inadequacy in meeting quality requirements such as performance and interchangeability.
Wrong and Too Complex Design: Wrong design decisions, complex designs beyond the need, wrong modular partitioning, wrong thread architecture will create problems especially in meeting quality requirements such as fault tolerance, interchangeability and performance.
Tight Schedule : In real life, there is never enough time to develop the project. Although there are software or designs that are not well designed with tight schedule, modules that are developed incompatible with this design will later appear as errors and performance problems.
Bad Development Practices: In large projects it is important that the software team has established development practices. It is important that these practices do not change from one component to another and are applied in the same way. Otherwise, each developer will reveal their own style and the result will be unmanageable software. Similarly, the lack of coding standards of the project or non-compliance with the existing coding standard are also important reasons for technical boron formation.
Engineers who are not competent for the job: It is important to work with experienced engineers for large projects. If we do the job with a team that has not previously worked in related technologies and has not received the necessary technology / software architecture training, it is inevitable that technical debts will occur.
Insufficient testing: Low unit test coverage of the software, insufficient test scenarios created in component tests, and lack of test automation are among the factors that cause technical debt.
Lack of Refactoring culture: Not foreseeing that technical debts will occur in the company and taking time for reorganization will cause technical debts to increase rapidly and become unmanageable.
Technical debt can be created deliberately to quickly get the product to the field. In this case, the team resents the difference of their technical debts and pays the debts later in accordance with their plans.
Technical debt, which is more difficult to detect and manage, is involuntary. Lack of Analysis, poor development practices, engineers who are not competent for the job are the main factors in the formation of these involuntary technical debts. Implementation or incorrect implementation of architectural design decisions taken at the beginning of the project causes architectural erosion. As a result of this erosion, technical debt is formed.

Technical Debt Examples:

• The fact that a regular and configurable error log infrastructure has not been created on a project basis, and simple error records such as printf, sys.log are added and then deleted or made into a comment line.
• Changing information such as IP address, data transmission period, which may change during system integration, in the code instead of the configuration file
• While developing a new component feature, copy/paste from another module. The result is repetitive code fragments and repeated efforts to maintain this code.
• Computers are powerful enough, the database can save thousands of data per second, as generally accepted software is not optimized.
• Adding a new library to the project to meet the current need without sufficient analysis also causes technical debt.

How is technical debt paid? Click on the link for the article.