Technical Debt - A catchall phrase?
leenaApril 6, 2017
Those who have driven in Bangalore know that how much tough it is to drive here especially during the peak hours @ signals like Silk Board. Everyone tries to get out of the signal as quickly as possible, not giving much importance to the shortcuts we take, like the wrong side, overtaking from left etc.
We complain about how tough it is to drive in Bangalore and the question that can be asked is how much we contribute to it or how much we try to correct it?
This is similar to the excuse we've for Technical Debt. The code is anyways messy, adding one more is not going to make any different. It was like this when I joined the project. We had time pressures so had to release it faster.
And this thought process ends up creating the Vicious cycle as follows:
And this is the beginning of the so-called Technical Debt.
And there is one more term that we all like to complain - Legacy Code. Below is one of the best definitions of legacy code I've ever seen.
Let's look at some examples of what we call as Technical Debt.
Credit: http://thedailywtf.com/articles/the-refactoring
The following is commonly seen - Ignoring Exceptions
And other common examples which I've not covered are:
- Code duplication
- Mismatching names
- Longer methods and/or classes
I am sure all of us seen variations of all these.
What is Technical Debt
Let's take a step back and look at what Wikipedia has to say about Technical debt:
Technical debt can be compared to monetary debt. Unaddressed technical debt increases software entropy. Technical debt is not necessarily a bad thing, and sometimes (e.g., as a proof-of-concept) technical debt is required to move projects forward.
And this is what Ward Cunningham, the person who coined the metaphor, also seemed to have in mind while he coined the term.
To summarise, it is not a license to create an architecture as follows, nor the license to create crappy code.
If we all agree that the above flaw is not considered as professional in other engineering streams, the same rule is applicable to Software Engineering too.
As prudent professionals, it is our responsibility to follow the four rules of simple design:
- Passes all the tests
- Expresses every idea that we need to express
- No Duplication
- Minimal methods, classes and modules
And this includes the following:
- Frequent activity of renaming classes, modules, methods, variables
- Applying Boy scout rule i.e. Leave the campground cleaner than you found it
- Delete the unused code courageously
Technical Debt Quadrant
Going back to the definition of Technical Debt by Wikipedia, it should be a result of a conscious, thoughtful and prudent decision than that of an unconscious one.
Martin Fowler uses a quadrant to explain similar concepts where he points out that it is not useful to discuss whether something is a debt or not, better ask whether it is reckless or prudent. The more the issues/flows are in the Prudent section, better it is.
Paying down Technical Debt
Every team will have technical debt, and it is normal because we learn with our products continuously so it is ideal to have prudent debts.
Another thing is that not all of them needs-pay off. Some of them might be in those areas where we hardly make changes.
So how to identify what needs-payoff? I would like to quote Henrik Kniberg here:
What is technical debt anyway? Anything about your code & development environment that slows you down. For example:
- Unclear, unreadable code.
- Lack of test automation, build automation, deployment automation, and anything else that could be automated that you do manually today.
- Duplicate code.
- Tangled architecture & unnecessarily complex dependencies.
- Slow, ineffective tools.
- Uncommitted code & long-lived branches (hides problems that will slow you down later).
- Important technical documentation that is missing or out-of-date.
- Unnecessary technical documentation that is being maintained and kept up-to-date.
- Lack of test environments.
- Long build-test cycle & lack of continuous integration.
And pay off them with:
- Continuous refactoring, applying Boy Scout Rule
- Use constant communications to improve namings
- Setup Continuous Integration, Follow Mainline Development
- Setup Deployment Pipeline [Automated Testing and Deployment]
- For long running rewrites or major design/architectural changes, use:
References
Following are some of the highly recommend books for improving the code quality and cleanliness:
Growing Object Oriented Software - Guided by Tests [known as the GOOS book]
The following are some of the articles/talks on the same subject:
Building a Culture of Code Quality - Bryan Helmkamp
The Technical Debt Trap - Doc Norton
Why do teams fail to sustain code quality?
A mess is not a technical debt - Uncle Bob
Debt Metaphor - Ward Cunningham
Technical Debt Quadrant - Martin Fowler
Sacrificial Architecture - Martin Fowler