[fsloth]

"...everything we do that is 'technical' has ... consequences that go beyond the technical: The mere fact that most of the technical things we choose to do are done for non-technical reasons is enough to establish that."

Aha! But people do things just for technical reasons that don't affect the users in any way.

One could claim that just refactoring code without changing anything is a "purely technical" exercise.

What I've seen developers spend time on, that has absolutely no effect on end users in a large C++ codebase:

* Changing old C-style string handling to std::strings

* Change naming convention to uniform

* Random formatting that should be done automatically but someone decided to do by hand

* Sundry "modernizations" like replacing vanilla C++ loops with C++ range based for loops etc

[jungturk]

To the extent that these changes actually improve the non-functional quality attributes of the system, those gains can be converted into business or customer utility.

Improved maintainability => lower innovation costs, and those savings can turn into profits and/or happier customers.

Improved security => reduced risk of exploit, and that improved posture can be turned into profits and/or happier customers.

I acknowledged that not all changes of the sort you list do yield actual improvement in the quality attributes.

[thebean11]

> One could claim that just refactoring code without changing anything is a "purely technical" exercise.

The reason is still partly non technical; the goal is to make future changes less costly or less dangerous.

[minitoar]

Does it matter that they are less costly or less dangerous for technical reasons? lol

[mannykannot]

The examples you give look more like inefficient resource (developer time) allocation - AKA Yak Shaving - rather than technical debt.

Nevertheless, people doing things for just technical reasons does sometimes create technical debt, as when doing so over-complicates the implementation to no observable end. So? If anything, these cases stand as counter-examples to the author's argument that technical debt is not technical.