It's because measuring those things is impossible. It's not like people haven't tried - look up cyclomatic complexity for example.
But programming is more like product design or urban planning than structural engineering or construction.
There's no formula for maintainability or technical debt in the same way that there's no formula for the best town design.
That doesn't mean that all towns are equal, or that we can't say anything about urban planning. It just means you can rarely make concrete rules about it.
> It's because measuring those things is impossible. It's not like people haven't tried - look up cyclomatic complexity for example.
Quantification is the basis of scientific process. Are you claiming programming or software systems cannot be a subject of scientific process?
That would be a really bold and blatantly false statement.
But if you mean "technical debt" is not measurable then we are in complete agreement and what I am saying is that if that's the case then talking about "technical debt" is useless and we should try to find other terms which would be more useful to describe software systems and allow us to base our decisions on more than feelings and intuitions.
Talking about "technical debt" of software system is no more useful than talking about its scent.
> Are you claiming programming or software systems cannot be a subject of scientific process?
I'm saying it's extremely difficult and expensive to answer most of the questions that you want to know through scientific experiment. Usually the best you can do is experience.
That's not a bold thing to say. There are plenty of areas that are really hard to study through experiments, but we can still learn things through experience. The whole field of psychology is just on the edge of being amenable to experiment, but it's not like we know nothing about human psychology.
Management is another field where it's more or less impossible to do scientific experiments to determine what makes the best manager, but again that doesn't mean we know nothing about management.
Very occasionally there are great scientific studies of software - e.g. that paper where they found that Typescript/Flow prevent ~15% of bugs in Javascript software. But most are along the lines of "we took some undergrads, gave them a tiny task, and measured how long it took them" which has no correlation with best practices for professional long-term projects - maybe even negative correlation. For example I suspect it would tell you that adding any comments to code is a bad idea!
> Talking about "technical debt" of software system is no more useful than talking about its scent.
Why do you think talking about its scent is not useful?
> That's not a bold thing to say. There are plenty of areas that are really hard to study through experiments, but we can still learn things through experience. The whole field of psychology is just on the edge of being amenable to experiment, but it's not like we know nothing about human psychology.
Management is another field where it's more or less impossible to do scientific experiments to determine what makes the best manager, but again that doesn't mean we know nothing about management.
And yet in both these cases we at least _try_ to come up with quantifiable results of our observations. The point is that without them we are not really capable of coming up with any meaningful conclusions.
> Very occasionally there are great scientific studies of software
For me it seems the body of software available to analyse empirically is large enough now to start doing it and it is happening. What's important is that none of the empirical studies I know measure anything named "technical debt".
>> Talking about "technical debt" of software system is no more useful than talking about its scent.
> Why do you think talking about its scent is not useful?
Because it does not provide any meaningful insight into what should or should not be done to improve it.
> And yet in both these cases we at least _try_ to come up with quantifiable results of our observations.
We do in software development too. I said that twice already. It's just almost impossible to actually find out concrete rules that way.
> without them we are not really capable of coming up with any meaningful conclusions.
Nonsense. Scientific experiment is NOT the only way to learn about the world. It is the best way where practical, but it simply isn't always practical.
Think about something like UBI. Using scientific experiments to determine if UBI works you would have to take N countries, have half of them implement UBI for 100 years, and half not. Good luck.
> Because it does not provide any meaningful insight into what should or should not be done to improve it.
It does. Code smell is usually used to describe code that is suspicious or uses practices that are known to be highly unreliable (e.g. regex). The thing to do is to either rewrite it in a more robust way or if you can't do that for some reason, to add a lot of testing.
But programming is more like product design or urban planning than structural engineering or construction.
There's no formula for maintainability or technical debt in the same way that there's no formula for the best town design.
That doesn't mean that all towns are equal, or that we can't say anything about urban planning. It just means you can rarely make concrete rules about it.