Hello, after having quickly taken a look at Parkinson’s law, let’s look today at the notion of technical debt. For the history of this fairly simple but oh so effective notion: wikipedia.

Roughly speaking, the idea is that each time you perform “quick and dirty” development (generally because someone demands a delivery date that’s too difficult to meet and therefore quality disappears, or because your development practices aren’t sharp enough -TDD, Unit Test, Pair programming, refactoring, etc-.) this same code will require you to pay interest over time. Each time you come back to this code, an additional amount of work due to its poor quality will be -on top- necessary.

Like a real debt, this one can accumulate until it makes a solution, a product, etc. completely inert. Remember that your code is not an asset but a cost: the several million lines of code in a codebase are not wealth but a constraint.

As this diagram shows (from Agilitrix 2010, ;) how convenient with the theme…) if you don’t reduce the technical debt, you will get a “dead core”. A screwed product.

I just spent a few days in Switzerland on assignment, I’m taking advantage of it to better express this idea of technical debt by calling upon the ideas of Uderzo & Goscinny: each time you let your piece of bread slip away, your code, without paying attention, you accumulate cheese everywhere in your application that will -little by little- prevent it from moving forward, until a certain immobility (it’s the application you’ll throw in the lake). It’s always difficult to convince decision-makers but it’s sometimes necessary to invest in reducing technical debt. (thanks again to Frédéric for his inspiration). Click on the image to access it in a readable way.