Aa a Developer I will define a Technical debt when a Team prioritise a deliverable with compromising code quality over fast delivery and eventually it needs to refactor to evolve or support new functionality.
As an Architect I will define a Technical debt, A design or implementation constructs that are expedient in the short term but that set up a technical context that can make a future change more costly or impossible.”
Pressure of delivery result to take some decision which are compromise the code quality or uses some work around.
and with the time teams take many work around to get away from previous work around and it piled up .
This overall situation result in Technical debt.
Technical Debt can impact in 2 places
- Adding New Feature.
- Maintaining Existing System.
Type of Technical Debt:
1. Source code level:
Source code is soul and body of your software, design and implementation represented by source code. The code can be subjected to review, inspection, and analysis with static checkers to find issues of finer granularity
When a system incurs technical debt at the source code level, the debt tends to hinder maintainability so that it will be hard to make corrections to the system when needed.
Reasons:
· Bad coding standards
· Code Clone
· Violations of coding standards
· Incorrect Comments
What we can do:
· Use of Code quality tools ex Sonar Qube to identify code issue
· Proper Document
2. Architecture level:
Architectural level debt are due to poor architectural choice . For these elements, the principal and the interest are often higher than for technical debt in the code. When a system incurs technical debt at the architectural level, the debt tends to hinder evolvability: The system will be hard to extend to new features, with their functional and quality attribute requirements, such as scaling to a larger number of users, processing different kinds of data, and the like.
Reasons:
1. Non-Scalable Platform
2. Complex Technologies for integration
3. Bad user Interface
4. Lack of data Persistency
What we can do:
1. Use project management tool across all the organisation
2. Select and Apply Architecture Analysis Techniques to Get to the Artefact
3. Define the Architecture Measurement Criteria
4. Review the architecture. If it is not documented, glean insights from team knowledge, source code, and the issues being tracked
5. When fixing a defect or adding a new feature request, look beyond the immediate implementation to see if there are longer-term design issues leading to technical debt
3. Production / Infrastructure level:
Some technical debt items are associated not with the code of the product but with the code of other closely related artefacts in software production: build scripts, test suites, or deployment infrastructure.
Resons:
1. Poorly managed password
2. SSL certificate mismanagement
3. Manual and ad hoc deployment
What we can do:
1. Architect for ease of deployment, observability, and automated processes.
2. Use infrastructure as code
3. Use managed services in cloud if possible
How to deal this in Real World:
One of our Client who is having legacy data warehouse system, most of the focus on business requirement. System is working fine from business point of view. Recently Team is decided to move to cloud based platform and in result it is assessing its current state. The observations are show System was having Technical debt as which has grown over the period of time.
Technical debt has been impacting the delivery and raising the concern for management.
How we have addressed the problem.
Source code level debt:
1. Due to lack of code management and attention there is lot of code duplication and irrelevant code was present in master branch.
Assessment: We have used SonarQube for validating duplicate code present in.
Result: 60% duplicate found.
Resolution: Code need to set identify and removed.
2. Code management: repository pattern is used here is mono Repo which is meant to simplify the dependency management but with increasing number of team member and absence of CICD process mono repo become a nightmare to work with.
Resolution: Mono repo segregated into multiple repos grouped on business use case. This results less conflicts and fast development time.
Architectural Debt:
1. Review found the indexing of Fact and Dimension tables is not optimised which was causing the performance issue in some cases.
2. System was using some Synchronous API for long running jobs which is failing in case of network failure.
Resolution: Encourage Async API for long running jobs.
Take Away:
I would say technical debt is very difficult to avoid with hard deadline and delivery pressure. But We can definitely reduce it with proper use of tool , following best practices , frequent review and defining clear way of woking .
