Technical Debt Edge Cases
Everybody talks about Technical Debt. Most of the time it’s always considered to be A. Bad. Thing.
Nobody talks about when it might not be a bad thing, or when some folks think Technical Debt exists and it doesn’t.
Technical Debt is a term invented by Ward Cunningham to explain what happens when we not keep our codebase in alignment with how we understand the problem.
Note that Ward is talking about something along the lines of hacking your code to get it to work even when it doesn’t reflect the way things work in the real world. Over time, Technical Debt has come to just mean hacking your code. As Ward points out at the end of the video, code that isn’t clean is more difficult to adjust later, which keeps it from being in alignment with your understanding.
So if you’re looking at your code and you don’t know why it works, or if you’re looking at your code and it’s so poorly constructed that others can’t immediately find the alignment between the code and the problem? You’ve got technical debt.
For all intents and purposes, history lesson aside, if you’re talking Technical Debt today, you’re talking about code that isn’t clean.
- Understanding of the problem – Note the presumption here: that the team has some changing understanding of the problem that evolves over time. As this understanding changes, the code should change to match the new understanding.
This is true in most commercial software development shops, but there is such as thing as Exploratory Programming, where you have no definition of the problem, you’re just searching for understanding. In this case, there is nothing for the code to align to.
- Economic Value – The value of your Technical Debt cannot exceed it’s economic value. There are many situations where what you are coding is economically worthless. In startups, for instance, stats show that 90-99% of the time the startup will not work. If the startup doesn’t work, then the code has no value. In fact, startups are a form of exploratory programming
- It implies a mapping that might not exist – Underneath all of this, which Ward skirts close to but never addresses is the assumption stated something like this clean code maps to a better understanding of a real-world problem than poor code.
This is the basis of all the confusion in the blogosphere.
The Agile and XP community grew up during the big growth days of OOA/D/P, and those roots show. There were a lot of problems with state mutability and unnecessary complexity in those OO solutions, and we’ve finally reached a point where anybody that’s interested can learn a few concepts, practice, and write OO code that doesn’t become a Charlie Foxtrot six months down the road. Maintenance programmers can then come in, understand what was done, follow the same rules, and adjust the code to fit the new understanding of the problem.
I believe this is the heart of what eliminating Technical Debt means. But that concept takes on a different meaning when your coding paradigm isn’t OO. In FP, for example, I’m looking to continuously refactor code every time I touch the codebase until there’s no more refactoring to be done. It’s not related to my understanding of the problem, it’s related to something like the natural algorithmic complexity of the problem, which is a different thing entirely.
I am concerned that we have this hammer we have found that works great for 5-40 programmers on a typical web project. We are then using this hammer whenever presented with any problem involving how programmers work.
April 4, 2016