I picked up a term that I have not used in all my years of programming, and I love it:

“Drift”.

As in “Specificaiton Drift”: you write the spec at time T, implement at T+1, learn something new about the problem domain in the process and adjust your implementation (you know, normal programming) at T+2, then at T+3 the spec doesn’t reflect the reality of the code base anymore.

But also “Knowledge Drift”, which maybe nobody uses as a term: where our personal understanding of the code is not up to snuff with reality. Maybe because teammates changed things during our vacation; maybe just because the system is too large to really know.

The fix to software entropy, to our lack of full understanding (which technically is unachievable in large, complex systems, but our brain fools us with a sense of familiarity anyway), always was and will be to stay vigilant.

The principle of Kaizen, of continuous improvement as an attitude, also likened to the Boy Scout Rule of cleaning up litter as you encounter it, this boils down to Always Be Changing. Code is malleable, so we need to update it to fit our understanding at all times, together. That’s how we pay of technical debt, but also cognitive debt, in our software design and in the artifacts (code, specs, docs) we produce.

Especially so in an age (or brief stint) of cheap code generation machines.

(I wish I’ve had felt my way around that term sooner in technical discussions (remember English is not my 1st language) because I would’ve used the heck out of it in my 17 years of note-taking! Now I need to update my Zettelkasten in many places to welcome this new-to-me term that captures how things, over time, drift apart. Luckily, my Zettelkasten is also malleable, like code, and can accommodate easily. It just takes my personal effort to think and understand.)