ABOUT

​

Is Technical Debt for Large Organizations Only?

Large organizations may have bigger debt due to complex systems and multiple changes. Because there are more players in big organizations the likelihood of Technical Debt is more in big organizations. Also churn of developers is another reason that contributes to more debt for bigger organizations. 

Smaller organizations will have comparatively smaller debt. An important point to note is manageability. Even a comparatively smaller Technical Debt can be very difficult to handle for a small organization. 

IT systems can be rendered unchangeable or unmanageable in both the cases if not attended to properly.

The same psychology is at play at both the places. There is interest and enthusiasm in building new systems. When systems are live, the goal is  invariably to make-do with what exists. Seldom do refactoring projects result out of strategy. Organizations are compelled to take them when no options are available.

​

Can You Avoid Technical Debt?

Technical Debt will creep in advertently or inadvertently even with the best of the teams. If you run a business, you are bound to incur Technical Debt. So the attempt should not be to totally get rid of it but to minimize it and keep it within manageable limits. It should be treated like the cost of doing business.

Technical Debt cannot be avoided.

Minimizing Technical Debt requires planning and buy-in from the company leadership. Here are best practices to reducing Technical Debt:
 

1. Do not overdo customization in packaged software: A packaged software should be configured and not customized by writing more code. Upgrades to the packaged software can render custom functionalities incompatible. Any addition to functionalities and features should be done through the package software and not on top of it.

2. Check attrition/turnover: Any member leaving the team creates a knowledge deficit in the system. New members take time to learn and may not achieve the level of competence of the original team.

3. Design for Decoupling: Services and components that are tightly connected are difficult to change. Changing one can adversely impact the others. Decoupled or loosely coupled components allow changes without impacting the smooth functioning of the system.

4. Design nimble systems that evolve and adapt to changing business needs: A system should be able to undergo infinite changes and upgrades without impacting its performance and stability. With time a system should become more and more stable irrespective of the changes it undergoes. It should be easy to retire components and add new ones as per changing business needs.

5. Limit people dependency: Put processes in place so that people do not become the bottleneck. The system should be so easy to understand and operate so that there is no need for an expert to run the show.

6. Limit programming languages and tools used in your organization:Different languages and tools will require different expertise. Ensuring availability of experts can become daunting.

7. Standardize the way design and architecting is done: Incorporate your best design and implementation practices in templates. Any new implementation should start with the templates. This will help achieve standardization and uniformity across your organization.

8. Modernize legacy systems: Systems that have been in use for long seem indispensable as they end up being the core of business. But the cost of running them can be huge. Such systems should be modernized phase wise if possible. Old systems that are past their shelf life should be retired and replaced with new modern implementations.

9. Budget for Refactoring: Systems that have been implemented recently should also be looked at for performance and efficiency improvements. It is a good practice to revisit and clean up the code base for poorly written or duplicate code.

​

Planning well to mitigate high Technical Debt is a good approach.

​

How to manage Technical Debt

The first step to managing Technical Debt is to accept that it exists in your organization and needs to be repaid every year. As long as code is written, there will be inefficiencies that creep in however diligent the IT team might be. Technical Debt is akin to the cost of doing business.

Once the existence of Technical Debt is accepted, the next step is to ensure the awareness of it. The leadership needs to understand it and track it just like the financial debt. Every organization should know its Technical Debt. It should make sincere attempts to know the sources contributing to the Technical Debt. The leadership should measure and track Technical Debt for determining the company's performance.

An organization should actively plan for ‘repaying’ Technical Debt every year.

​

Avoiding High Technical Debt

Use approaches that introduce lower Technical Debt.
 

1. Use pre-tested, prebuilt components as much as possible

2. Design loosely coupled systems using microservices

3. Use modern techniques for design and architecture

4. Build a nimble, changeable system for changes are the only constant.

5. Simple intuitive code and flows that are easy to handover to new team members

6. Adopt newer, faster and easy to use technology and tools

7. Allow for time and effort for the team to do proper work

8. Emphasize on design upfront

9. Try to build a culture of avoiding short-cuts for quick gains

Planning to Manage Technical Debt
 

1. Organizations should plan for Technical Debt in similar ways to financial debt as both have the dubious potential to derail the business of a company

2. The leadership/management should plan to Define, Identify, Measure and Address Technical Debt

3. Every year an adequate budget needs to be allocated to attend to the ‘Interest’ of Technical Debt i.e. to perform projects for refactoring, updates or changes

​

​