Fixing Technical Debt has been a passion of mine for a very long time. It is often the most impactful endeavor that software developers can do to affect the business in a positive manner. But before we can correct technical debt, it is important to understand what "debt" is from a technical software perspective.
Ward Cunningham coined the debt metaphor a long time ago to explain the costs associated with software development and speeding the process up. He compares it to borrowing money from a bank and how that allows you to do something beyond your current finances, such as buying a house. The catch is that you have to pay back the loan plus interest. You can see a video and transcript of Ward explaining the metaphor here.
http://agile.dzone.com/articles/understand-high-cost-technical
Like most things in the software business, a balance is required. Balance between "borrowing" in order to increase feature availability and re-paying the debt incurred as we increase our knowledge and experience.
Over the course of my career, I have worked at all sorts of companies from the start-up with 6 people to the largest multi-national corporations. What is interesting, is the lack of balance can be found at companies of all sizes.
What I have found is that the startup mentality is often to assume more debt in the hopes of becoming profitable through the acquisition of customers. This is done by creating a product and adding features that are valuable to a customer base. However, as the company and product matures, you reach a point where the income-to-debt ratio begins to take its toll. Meaning that you reach a point where the company must start paying back on its debt or you will see a diminishing rate of return on the work you can complete.
This transition is often one of the hardest for a company make and the earlier that a product can make the change, the better off the company will continue to drive an engine of growth. In fact, the technical debt metaphor explains that if the cost of the interest on the debt increases to an amount that is greater than revenue, the entire growth engine to stalls. This is obviously a disaster scenario for any company.
So how do we address technical debt? This is not an easy question to answer, as each case can vary greatly. However, there are some simple steps that can help drive the decisions to make the journey a successful one.
1. Consistent Vision
This is one of the single more important aspects of building a product. You MUST know what the long term vision of the product/business is. This is a 50,000ft view of things and I like to think of it as a compass point that point that direction that we need to head. Everything that we do should be measured against this vision/direction. One of the major generators of technical debt, especially in the early stages of a products lifecycle, is not understanding the needs of customers and frequent changes in direction. By the time you are ready to address your technical debt, you should have a good foundation on what problems your product solves and how it solves them. This should set the Vision.
A consistent vision is important for understanding and building new feature functionality as well as addressing technical debt. More often than not, I have seen, the greedy shortsightedness of the business try to build a feature that is counter to the vision of the product because they are chasing a specific customer. If you continually chasing business or attempting to be everything to everyone you will quickly find yourself under a mountain of technical debt.
2. Identify Milestones
Milestones provide 2 different pieces of information to the company that is trying to solve technical debt. First, milestones help define problem areas within the business and secondly, they provide for a goal and timeline that aligns with the vision. Milestones are the main driver of work and will detail the process and the acceptance criteria.
3. Disciplined Execution
The last item to address your technical debt is Disciplined Execution. This is where the rubber meets the road, however it is important that the execution is well thought out and meets the milestone that it falls under otherwise you could be setting yourself up for adding debt instead of paying it off. Disciplined execution means building off of simple concepts to grow a products functionality. Do not attempt to predict how things will change or what will be needed in the future, instead build as simply as possible to meet the objectives of the Milestone.
Following this simple approach to tackling your technical debt can pay huge dividends to the products that you build and also to meeting and exceeding customer expectations. Assuming debt is often a necessary part of building software, but that also means that paying off that debt is also necessary. Without a plan to address debt, it will continue to grow with defaulting being the final outcome. Good luck! I would love to hear your thoughts & feelings on technical debt.
