eventually that program simply does not contain any understanding
That reminds me of
the primary aim of programming is to have the programmers build a theory of the way the matters at hand may be supported by the execution of a program
This is Pater Naur in Programming as Theory Building. It argues that we must keep the programmers who understand a program together with the code and not treat them es replaceable.
If this is technical debt, it means we can create technical debt by replacing programmers in a project. It implies that technical debt is not a property of the code. The article remarks something similar:
if “Code I don’t like” is the bar to qualify as technical debt, you’ll be refactoring the entire project every time you hire a new employee who has big opinions.
To be honest, lately I find the concept of technical debt more confusing than helpful. Maybe we made to mistake to label too many things with it? There is “we intentionally take a shortcut” and “the environment changed” and “we forgot about something”. Three very different cases but we usually the symptoms of them all as “technical debt.” However, they need different strategies to fix and this gets all muddled up if we only talk about a single concept.
we can create technical debt by replacing programmers in a project
Many teams I see in super big trouble have none of the original programmers anymore. People get scared to change entire swathes of “scary parts” of the code because they include vestigial elements of concepts which don’t exist anymore or even clash with the current way the systems works. Programming would be revolutionized if management didn’t accept massive turnover as the norm.
Take a look at your nearest corporate wiki. I can almost guarantee it’s a mess because most companies should never have wikis.
What’s the alternative? Documentation in the codebase? Design docs? The article seems to suggest code rewrites as the solution. However, there may still be knowledge outside of the code (eg. ops playbooks) that still needs to go somewhere.
I’d be curious to see if someone has already made a good parallel between tech debt and garbage collection. GC is a problem we understand well, and perhaps there’s some basic techniques that can be easily ported.
It’s a pity that collecting data on TD is so difficult.
That reminds me of
This is Pater Naur in Programming as Theory Building. It argues that we must keep the programmers who understand a program together with the code and not treat them es replaceable.
If this is technical debt, it means we can create technical debt by replacing programmers in a project. It implies that technical debt is not a property of the code. The article remarks something similar:
To be honest, lately I find the concept of technical debt more confusing than helpful. Maybe we made to mistake to label too many things with it? There is “we intentionally take a shortcut” and “the environment changed” and “we forgot about something”. Three very different cases but we usually the symptoms of them all as “technical debt.” However, they need different strategies to fix and this gets all muddled up if we only talk about a single concept.
Many teams I see in super big trouble have none of the original programmers anymore. People get scared to change entire swathes of “scary parts” of the code because they include vestigial elements of concepts which don’t exist anymore or even clash with the current way the systems works. Programming would be revolutionized if management didn’t accept massive turnover as the norm.
I think it’s the responsability of the people to understand the code instead of getting scared by it. Being scared = lack of understanding.
[Comment removed by author]
What’s the alternative? Documentation in the codebase? Design docs? The article seems to suggest code rewrites as the solution. However, there may still be knowledge outside of the code (eg. ops playbooks) that still needs to go somewhere.
I think he means to have docstrings generated into docs, so at least the person changing the code has immediate access to the human text.
TL,DR - technical debt is a thing, complaints about corporate wikis and KM, consider rewriting your product if technical debt is bad.
This blog entry doesn’t really add anything to the linked Ward Cunningham video.
I’d be curious to see if someone has already made a good parallel between tech debt and garbage collection. GC is a problem we understand well, and perhaps there’s some basic techniques that can be easily ported. It’s a pity that collecting data on TD is so difficult.