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.
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. This neat project uses some building skills with networking, software, and IFTTT.
- Nano Air S1 Pump
- 8ft Airline Tubing
- Clippard ET-2-6 6V DC Electronic Valve
- Airline Check Valve
- Adafruit Huzzah ESP8266
- FTDI Cable
- Solid State Relay
- TIP120 Transistor
- 2x Panel Mount DC Barrel Jacks
- 2x Terminal Block
- 2.2k Ohm Resistor
- 2x Barrel Jack Tips
- 5V DC Power Adapter
- Extension Cord
- Glass VOSS Still Water Bottle
- 3x No 10-32 x 3/16″ Hose Barb
- 12″ x 1/8″ Diameter Round Brass Tube
- 1/4 20 5/16″ Brad Hole Tee Nut
- Wood for Project Enclosure
- Wood for Tank Base
- Silicone Caulk
- E6000 Adhesive
- Drill Bits
- Clear or Colored Hand Soap
Tricks of the Trade
This week Will discusses the Pareto Principle or 80/20 rule. The 80/20 rule may not always be 80/20 but can be 90/10 or 70/30. Certain things have an outsized impact. There may be 20% of your code that is running 80% of the time. The best place to optimize is the code running the most. This pattern goes beyond development and can be applied to life skills. Look for the outsized in life, the 20% that will give 80% of the value.