What is a Kludge?
As per Wikipedia, a kludge (or kluge) is "a workaround or quick-and-dirty solution that is clumsy, inelegant, inefficient, difficult to extend, and hard to maintain. This term is used in diverse fields such as computer science, aerospace engineering, Internet slang, evolutionary neuroscience, and government. A software kludge (often called 'spaghetti code') is frequently the result of hacking."
As agile developers we have all implemented kludges at some time in our careers, usually to complete a given feature or story before the sprint ends. The idea is that at some point in the future, time permitting, we will circle back to the kludge and refactor it into a more elegant solution. It is such kludges that form the basis of Technical Debt.
What is Technical Debt?
Ward Cunningham coined the term technical debt. He described using the debt metaphor as a way of explaining the amount of code refactoring he did on a Smalltalk project. Technical debt (or code debt) reflects the implied cost of deferred rework caused by implementing a short-term fix (or kludge) to close a story. If the rework or "principle" is not "repaid" (completed), it will accumulate "interest", making it harder to implement changes later. The points to complete the story are "borrowed." Therefore, the rework to correct the short-term fix is backlogged and estimated, but the points do not get added to velocity. This would have a doubling effect as points were earned twice for the same functionality.
Martin Fowler created this quadrant known as the Technical Debt Quadrant to address how teams accumulate technical debt. In a nutshell, teams either deliberately or inadvertently pile on debt. Those decisions are either prudent or reckless.
Technical debt cannot be ignored. Every team should have a plan to address it. Start by using the Technical Debt Quadrant to identify where the issues are on the quadrant. Then create what I call a "Technical Debt Manifesto" to better manage the technical debt. Here's a sample Manifesto with only the principles the team will follow. A team-specific definition of technical debt, similar to above, should also be added:
Team Technical Debt Manifesto
Like all debt, we will strive to not incur it from the start. We will handle technical debt as follows:
No short-term fixes to close the story
Strict adherence to the definition of "done"
Diligence in code reviews
Refactor (pay down the debt) when/where appropriate
Use good design practices, i.e. TDD
Utilize appropriate unit tests/code coverage
Once created, add the manifesto to the team working agreement or team norms. Most importantly, make it visible on your team wall, either physical or electronic (Jira, etc.) or both. Modify it, along with definition of "ready" and definition of "done," as needed during the team retrospective!
