Hacker News Reader

Comment by mkleczek | Hacker News Reader

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?

View on HN

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.

> Code smell is usually used to describe code that is suspicious or uses practices that are known to be highly unreliable (e.g. regex)

I think this sentence illustrates very well the root of our disagreement.

Saying "are well known to be highly unreliable" without any backing _facts_ is the sad state of affairs in IT industry.

I am keen to see a research done with scientific rigour that would show that regex is highly unreliable.

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?

Reply on news.ycombinator.com