How to Identify Technical Debt

The term technical debt can be misleading and confusing. It is generally referred to as a metaphor referencing the consequences of system design or software architecture in a codebase. Technical debt can be difficult to identify directly so developers need to use clues that can be broken down into social cues, code cues, and testing/deployment cues. When developers don’t like dealing with a particular area of code or frequently complain about working in a certain part of the codebase that is a social cue that there may be technical debt in that area. Overly tight coupling, objects with too much control, and incoherence between components are all cues in the code that there is technical debt that needs to be dealt with. Finally in testing and deployment if there is a lot of friction setting up the environment or testing fails irregularly due to brittleness there may be technical debt in the codebase. Episode Breakdown * 14:50 What is Technical Debt “Technical debt (also known as design debt or code debt) is a metaphor referring to the eventual consequences of any system design, software architecture or software development within a codebase.” The term technical debt has been overused and under utilized. It refers to areas of a code base where tradeoffs were made that no longer are necessary and cause problems for developers. Identifying technical debt can be a daunting task. * 19:43 Social Cues Social cues are clues to potential technical debt that are not code based but based on human interaction with the code. When developers don’t like dealing with certain parts of the codebase or frequently complain about interacting with that part of the system a social cue indicates there may be technical debt in that part of the code. End user complaint about parts of the system breaking that suffer from technical debt. Technical debt can also make predicting efforts to make changes to the system difficult. * 27:57 Code Cues Code cues may not be overt technical debt but clues that technical debt exists in the code base and where to look. Overly tight coupling to other parts of the code, god objects, and incoherence between components show the code has some technical debt. Inconsistent implementation patterns such that it is obvious when different leaders where in charge also indicates debt. Finally dead (or undead) code, spaghetti code, and copy/paste code are all indicators for technical debt. * 42:11 Testing/Deployment Cues High friction in setting up a deployment/testing environment or frequent testing failures due to brittleness of the codebase indicate technical debt from the testing environment. Overly tight coupling of components leads to the inability to simulate failure conditions or alter configuratioins for different deployment scenarios. Finally difficulty in automation of deployment scripts shows the existence of technical debt. IoTease: March is for Makers March is for Makers is a movement started by Saron Yitbarek of Code Newbie and Scott Hanselman of HanselMinutes for their respective podcasts. All month long they will be interviewing makers and discussing hardware. Though not officially part of the movement to show our support we are dedicating IoTease this month to fun family projects that can be done each week. Blüp: The Bubble Notifier A fun family project, this week highlights Blup: The Bubble Notifier. Instead of being notified via sound, vibaration, or blinking lights use bubbles in a liquid mixture of water and soap.