We all experience technical debt when building software, especially software that has been around for years. Most of us have likely encountered code that we are loathe to touch and modify. At least, we don’t touch it twice. We might change things once, but when it doesn’t work as expected, most of us put it back in it’s previous state and move on to something else.
At the same time, it’s hard to define what technical debt is or point it out to managers, who often can’t grasp the concept of why technical debt matters to a development team. They can’t understand the reasons why new code built on older code takes longer and longer to produce. It’s a nebulous concept that can baffle both people new to software development and those with years of experience.
I ran across a few articles that talk about technical debt. This one notes it’s commonly used as a phrase and also, it’s inevitable. There’s a short video from Ward Cunningham, who is said to be the inventor of the term. It’s interesting because the explanation isn’t bad code, it’s more that we don’t always understand the problem when we write code, especially at the beginning. As we have a disagreement between what’s coded and what’s needed, we accumulate debt. Ward talks about refactoring regularly as we gain understanding.
There is another piece that uses the Chernobyl disaster as a comparison with software development. This one looks at cost-cutting in both situations. The emphasis in software development is something Jeff Moden will appreciate: developers not writing robust code. There is also a section on designing to meet only 95% (or less) of perceived use cases, which I think is just reality. We can’t write software, in any practical sense, to cover 100% of use cases.
The final section talks about incomplete testing. While software development has gotten better here, there is still plenty of work to be done, especially with database software. I find far too few database engineers wrap tests around their code and often have problems with new data or when code is refactored. A few more tests added early often prevent issues later, or at least, save time when debugging. This is one place I think AI might really help with labor savings by writing these tests for us.
Technical debt is a reality of life. We have imperfect engineers, we have the pressures to get things done, the increasing complexity of software systems, and perhaps most of all, the pressure to keep moving forward with something new instead of refactoring something old. I don’t have any great solutions, but I also do see software developers working better than they did in the past. That gives me hope for a future where software is embedded in more places and used more every day.
Listen to the podcast at Libsyn, Stitcher, Spotify, or iTunes.
“We can’t write software, in any practical sense, to cover 100% of use cases”
Absolutely and anyone arguing that you should be able to doesn’t understand development.
In addition I’d say miscommunication between the client and developer also add to your debt by causing the developer to go back and re-do something simply because the client wasn’t %100 clear on what they wanted and incorrect assumptions were made by both sides.
I’ve had this miscommunication issue both when I was an independent consultant who did custom reporting and even now as an employee writing reports for persons within my company. I can’t make my superiors understand why it is when they want something custom they need to explain it to me like as if I never worked with them before so no assumptions are made. We recently got bitten in the backside by this exact thing. I spent many hours completely overhauling a mission critical report and because I was not given all possible use case scenarios for the report it ended up being developed in a way so that it works for most cases but not every single one. Luckily the ones it does not work for are the few and those users can still use the old version for that. This was a perfect example of why they (my supervisors) need to pretend like as if I know nothing about how the company does things when asking for a custom report and even after that clear example of why I still run into issues with getting %100 of what is really needed thus adding to my debt.
Agree, and I often look to get lots of feedback during the process, showing intermediate results. That way I don’t go too far down a report without a client seeing it.
I also write tests, and add strange data, trying to be sure I’ve covered not only what I think the client wants, but what other strange things I might not anticipate.
LikeLiked by 1 person