Technical Debt

August 26, 2014 · 1 min read

If any of you don't know about the concept of Technical Debt in your projects, this is a good presentation about it and how to handle it.

Some would say any code that doesn't have tests written for them is debt.

Also the broken window analogy from the Pragmatic Programmer, where if you have bad code the whole thing can start to fall apart is a good one.

Or if you have to do something quickly, and can't design or re-factor and much as you want, you might take on that debt with intentions of "paying it down" in a later sprint.

The debt analogy is easy to communicate to managers and other developers on your team and can improve your code quality and help your project stay alive. Pay down your debt!

This article is part of the GWB Archives. Original Author: Aligned

New on Geeks with Blogs

  • We Won The One Award I Actually Care About

    Full Scale made the Inc. 5000 for the fifth year straight, the 12th listing across my three companies. Here is why the one award you cannot buy is worth stopping for.

  • Your Customers Build the Features Now

    I let a tool I liked sit dead for a year rather than build the features I wanted. An MCP server meant I never had to, and your customers can do the same to your product.

  • Get the Size of a Directory in Linux the Easy Way

    du -sh for the quick answer, ncdu for the cleanup, df for the disk itself: every command for checking directory size in Linux, plus why du and df never agree.

  • Vim Search and Replace: The Ultimate Guide

    One :%s command replaces every match in a file before a find dialog would even open. The Vim substitute patterns worth the muscle memory: flags, ranges, capture groups, and multi-file edits.