Evolution of Architecture-2-How to Pay the Technical Debt?

Before this article you can read What is Technical Debt.

It is not always easy to identify these technical debts within the project. In this regard, software architecture researches work on systematic methods. The increase in errors in the work list, decrease in sprint speed, increase in end-user complaints are the most basic indicators of increased technical debt. Technical debts do not pose a serious problem for the project if they are paid early.
The first stage of the technical debt settlement approach is the identification of technical debt and the establishment of awareness about technical debt payment.
The second stage is the measurement of technical debt. That is, how long the correction will take and determining what benefit will be gained from this correction.
The next phase is prioritizing technical debt and incorporating it into the development plan.
The final stage is the payment of technical debt, that is, related development activities. Refactoring is the best-known method of reducing technical debt. Refactoring is defined as the external behavior of the software remaining the same while the internal structure of the software is corrected. Some of those;

• Discarding repetitive codes,
• Reducing cyclomatic complexity
• Reducing component dependency (coupling) and increasing inter-component cohession)
• Increasing the legibility of the code and ensuring code ownership as a team
• Correct application of design patterns.

So, refactoring does not mean software rewriting, debugging, or user interface improvements. Similarly, when it is determined that the current technology or library does not meet the needs, transition to new technology is also a debt payment method.
From a project management point of view, managing technical debts with risk management processes is another recommended approach. Firms that want to produce products quickly make tradeoffs between cost, time and technical constraints. As a result, these companies succeed by managing their technical debts with risk management.
If the technical debt is not managed well, the risks that will arise are listed below:

• System downtime
• Vulnerabilities
• Low customer satisfaction
• Brand image deterioration
• Increased maintenance and emergency response costs
• Poor performance
• Low reliability.

Technical Debt Management with Agile Process

An innovative approach has been adopted to pay off technical debt in agile processes. In this approach, new features and bugs are added to the project backlog, as well as Architectural Features and Technical debts. Each type of job is shown in a different color as shown in the illustration below. The basic approach is summarized as adding new features and bugs, as well as Technical Debt and new Architectural Features into each sprint. Thus, debts are made together with basic needs (defents and new features) without accumulating.

What happens if the technical debt is not paid on time?

Well, since it is not always possible to create ideal conditions, how can we successfully complete the project in non-ideal conditions? New researches and methods in the field of Software Architecture focus on new approaches to technically manage projects that do not start under the most ideal conditions due to these technical and managerial constraints.
As a result of technical debts, quality requirements related to performance and continuity cannot be met at the end of the project. This situation is expressed figuratively by the term “Technical Bankruptcy” in the corporate software architecture. So the current software is too badly designed to be recovered, and all your efforts will be in vain.
In order to avoid technical bankruptcy, companies that manage systematic projects have started to adopt technical debt management as one of the basic practices.

Technical Debt and Software Architecture Relationship

Research on technical debt has correlated shorthand approaches to architecture with high software maintenance and development costs.
Technical debt formation can be prevented by making architectural decisions that will best manage architectural concerns. In addition, situations such as deviations from architectural decisions and increase in dependencies are determined at an early stage, and it is aimed to identify the architectural debt at an early stage and correct it by reorganization. While the code technical debt can be determined with code analysis tools, software architects are needed for the detection and correction approaches of architectural technical debts.
Established software architectures approaches can set up the architectural life cycle that can manage technical debt, taking into account short-term and long-term quality characteristics. Tools and approaches should be adopted that will bring the relationship between architectural decisions and code closest. This should bring architecture and code closer together.

Dependency charts are a tool that can be used to identify architectural technical debts. Too much dependency is seen as technical debt as it will reduce exchangeability. The detection of layered architectural structure violations in layered architecture is similarly a technical debt detection method.
When different architectural perspectives are analyzed in architectural design, it will be possible to detect technical debts at an early stage. With architectural analysis approaches such as Architecture Tradeoff analysis Method (ATAM), trade-off points, sensitivities and risks can be determined, while technical debts can be determined. Reusable architectural approaches can be reconfigured taking into account technical debt.

How to Avoid Technical Debt Formation:

In the ideal world, when starting a project, software architects and developers are expected to have a certain level of technical and business knowledge about the project. The team should have enough time at the beginning of the project to deduce the architectural requirements and define the quality attributes scenarios from these requirements. Alternative architectural approaches and technologies should be evaluated in the architectural design to best meet these scenarios and the most appropriate one should be selected. The designed architecture should be analyzed and the risks should be identified at an early stage and solutions should be sought. Before starting development, the reference architecture should be formed and design patterns and tactics that complement this reference architecture should be determined.
When development begins, code outlines should be available for the team to easily develop established practices, coding standards, and patterns. The software architect should conduct code reviews from the first stage and should not tolerate architectural erosion.
All this ideal world scenario we are talking about is the approach normally covered in architecture books and tutorials. In summary, systematic good engineering practices will prevent the formation of technical debt. Again, with the help of peer review, Architectural Tradeoff Analysis Method (ATAM), tests and code analysis tools(like sonarcube), technical debts should be detected at an early stage and resolved early.

Next article discusses Refactoring vs Rewrite.