As a general rule all software development teams will create technical debt during the construction of their product. Creating this debt is in no way an indicator that the team is bad or not talented, but rather is an indicator that they understand that there are always tradeoffs when building an application. The fact of the matter is we are in the business of building applications which need to get to market and while building these applications we will be faced with decisions about trade off's.
Now I stated that creating technical debt is not any indicator of talent, but I will say that not creating an action plan to resolve this technical debt is a major indicator of experience. All software teams must maintain a list of items (non-business features) that need to be addressed at some point in the future. They need to mandate that this list be reviewed on a regular basis and priority be put on each item along with an action plan.
What counts as technical debt? .... Anything :) No really:
- Design trade offs you make
- Areas in code which could be simplified by the addition of a new tool or library (this may not have been a technical trade off at the time of construction, but new libraries could simplify the code.
- Areas in code 'that are not to be touched for fear of breaking' (you KNOW your projects has these dark corners)
Why Technical Debt is created?
When faced with a decision in regards to 'simple, quick, easy but not the best' or 'longer, more complicated but right' many times we reach for the 'easy button'. Reaching for this easy button is ok, but only as long as you understand the tradeoffs. Deadlines loom and we 'cut to finish'. Poor decisions were made by the team The team lacks the experience to make good decisions (not normally the case, but it can be)
Why Technical Debt is a burden on your project?
- It creates roadblocks for new development
- Can increase complexity in your codebase making new features more difficult to create
- Causes re-work to be performed in the future, which could take longer than had it been done 'right' in the first place
Why having the list is a good thing?
- Keeps the list visible and if it is visible it will receive attention
- Keeps people informed of bad (potentially bad) tradeoffs which were made in the past
- Keeps people informed of potential refactor points
Why having the list is a bad thing?
Admits to others (especially management) that your code may have flows (I actually see this as a good thing, but others do not) Reminds you of all the bad decisions you made... wait that is bad... NO
How we maintain our action plan for Technical Debt?:
Our team has created a list in our team wiki and grouped the items in the list by product feature. Each team is expected to add items to this list as they come across items in code which need to be addressed in the future.
When we add our items we provide the following level of information:
Original Reason for the debt (if known):
Risk of change: (high, meduim, low)
Risk if not changed:
Date/Release Debt removed:
At the end of the day the code you build is the code you are going to be required to maintain over the long haul. If you make the decision to not activily address your technical debt not only will your pain increase while working on your codebase but your customers will start to suffer because the cycle time to create new releases will increase and new features will flow slower and slower.
Till next time,
04-09-2010 6:20 AM