4 ms·

The longer I am in this industry the more I am disappointed about the fact that instead of using disciplined, quantifiable processes we are more and more in the

The longer I am in this industry the more I am disappointed about the fact that instead of using disciplined, quantifiable processes we are more and more in the realm of poetry with "analogies" or "metaphors". This kind of language - while sounding deceptively smart - does not help in any decision making because the terms are neither measurable nor actionable... Just meaningless. What we need are answers to questions like: how do we measure maintainability of software systems? How do we compare solutions and select them? How do we decide on what investment in making the software better is worth pursuing? Is "tech debt" even something that can be measured and actioned upon? How do we know if our changes to the software made it bigger or smaller? How do we know its impact on the bottom line?

barrysteve 3y ago
Who will pay for it. I've seen this line of reasoning since at least the mid 90s. Everybody knows in the whispers of their soul that an empirically mapped out programming culture, is a dead one. I can see how to tie together all the publicly available knowledge on programming into truthfully-easy to understand education material. People like Casey Muratori are selling the game of programming out from the bottom up. (and good for him). Why do it when we have to sell our skills today to put bread on the table?
IshKebab 3y ago
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.
- mkleczek 3y ago
  > 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.
  - IshKebab 3y ago
    > 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?
    - mkleczek 3y ago
      > 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.

barrysteve 3y ago

Who will pay for it. I've seen this line of reasoning since at least the mid 90s. Everybody knows in the whispers of their soul that an empirically mapped out programming culture, is a dead one. I can see how to tie together all the publicly available knowledge on programming into truthfully-easy to understand education material. People like Casey Muratori are selling the game of programming out from the bottom up. (and good for him). Why do it when we have to sell our skills today to put bread on the table?

IshKebab 3y ago

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.

mkleczek 3y ago
> 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.
- IshKebab 3y ago
  > 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?
  - mkleczek 3y ago
    > 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.