Live data from Hacker News

The Economic Benefit of Refactoring

martinfowler.com

121–130 of 132 posts

Re: The Economic Benefit of Refactoring

#121

Earlier quoted context omitted.

No this isn't mindless reinventing --- this is finally having clear empiric evidence for something that we knew the entire time. This is a huge relief! Next up is demonstrating the AI is more productive with better programming languages.

Haha, queue a big argument over what “better” means for programming languages.

They're the ones AI is more productive in....

(It's an interesting question though - my prediction would be that AI is best in the languages it consumed the most examples of, and I reckon the size of the StackOverflow site for each language would be a rough proxy for that).

Re: The Economic Benefit of Refactoring

#122
post #111

Earlier quoted context omitted.

They'd be 10x better than us already if task tedium was the problem. It's design sense that they're missing. I find that in the areas where people think that LLMs excel at coding and don't like doing manually it's usually because the human was inclined to slop out repetitive boilerplate and thought that was the only way. Tests are usually like this, sadly. LLMs are definitely good at providing reams of duct tape (whi…

> They'd be 10x better than us already if task tedium was the problem... the areas where people think that LLMs excel at coding and don't like doing manually it's usually because the human was inclined to slop out repetitive boilerplate and thought that was the only way. There is so much work out there that is repetitive / boilerplate / tedium. If you get to personally work on interesting work more than 50% of the ti…

IME if a technical task is tedious and repetitive it is nearly always because the system was badly designed or because it wasnt automated properly.

My job is automation and system design, so if I can't fix or work around these things that reflects poorly upon my skills.

Some people treat writing tests as inherently boring because their test frameworks usually suck. If they don't suck and a test is a very close approximation of a spec, it's not boring at all, especially if you use it as a means of codifying a spec before implementation.

Re: The Economic Benefit of Refactoring

#123

I really enjoy refactoring. Like, doing it by hand (5 miles uphill in the snow both ways) rather than AI. I don't even understand why I enjoy it, because if done right, there's no visible change. When people ask me why I'm so pumped up after having worked on the codebase all day long, I can't give them any sort of answer that makes sense (coming from a small business with a smaller dev team). It's just... "I'm future…

> I can't give them any sort of answer that makes sense ... Pride of workmanship. For those who understand, no answer is needed. For those who don't, no answer will work.

Ha, many years back I had to write a template processor for some system configuration handling. Manager told me last guy did most of the work so test and wrap it up. I instead had to throw it out as it was so crappy, wrote much smaller code, with no dependency and really put soul in logging where it showed cleanly how tool is navigating all directories, picking placeholders and replacing with values and so on.

No one really cared but it satisfied me and make me really happy.

Re: The Economic Benefit of Refactoring

#124

Earlier quoted context omitted.

Do you have citations? Everything I’ve read have said they have an overwhelming bias to Python; eg https://arxiv.org/html/2503.17181v1 and https://arxiv.org/html/2505.13004v1

Agents love writing Python, but it turns out they're not amazing at it. https://autocodebench.github.io/

I’m not really sure how to read those charts, but it’s completely possible that python did not work well for the approach they were trying.

I would be the first person to give up python for kotlin or some other more natively typed higher performing language. But the python bias is so far too big to ignore.

Re: The Economic Benefit of Refactoring

#125
post #105

This is interesting, but I think it would be even more interesting to see a comparison of the token cost of adding a new feature, in the original codebase vs the refactored one. You'd think/hope that the cost of adding the new feature would be lower when starting from the refactored codebase, indicating that refactoring makes economic sense in the long run by lowering the cost of adding new features.

That's what I've shown in this article. The token consumption shown is for adding a new feature (the same feature each time -- in a sub-agent) after every refactoring is applied. I didn't actually capture the token cost of the refactoring. That was a miss, and I'm making sure I do that in the future.

Kind of you to engage! Ahh, ok, I misunderstood. Very cool! I think maybe it would have helped me if you had given a one-or-two-sentence description of the "representative change" in the main text, to make it a bit more concrete up-front? But possibly just a 'me' issue...

Re: The Economic Benefit of Refactoring

#127
post #121

Earlier quoted context omitted.

Haha, queue a big argument over what “better” means for programming languages.

They're the ones AI is more productive in.... (It's an interesting question though - my prediction would be that AI is best in the languages it consumed the most examples of, and I reckon the size of the StackOverflow site for each language would be a rough proxy for that).

If it was as simple as that we would have far fewer programming languages even for humans today.

Re: The Economic Benefit of Refactoring

#128
post #122

Earlier quoted context omitted.

> They'd be 10x better than us already if task tedium was the problem... the areas where people think that LLMs excel at coding and don't like doing manually it's usually because the human was inclined to slop out repetitive boilerplate and thought that was the only way. There is so much work out there that is repetitive / boilerplate / tedium. If you get to personally work on interesting work more than 50% of the ti…

IME if a technical task is tedious and repetitive it is nearly always because the system was badly designed or because it wasnt automated properly. My job is automation and system design, so if I can't fix or work around these things that reflects poorly upon my skills. Some people treat writing tests as inherently boring because their test frameworks usually suck. If they don't suck and a test is a very close approx…

Don't disagree that that's the system not working well.

You're lucky to be in a system that works out for you. Not everyone is in such a lucky position. LLMs help automate the tedium out of their job, and hopefully, have a bit more extra energy to make a better system within their immediate locus of control.

Re: The Economic Benefit of Refactoring

#129
post #122

Earlier quoted context omitted.

IME if a technical task is tedious and repetitive it is nearly always because the system was badly designed or because it wasnt automated properly. My job is automation and system design, so if I can't fix or work around these things that reflects poorly upon my skills. Some people treat writing tests as inherently boring because their test frameworks usually suck. If they don't suck and a test is a very close approx…

Don't disagree that that's the system not working well. You're lucky to be in a system that works out for you. Not everyone is in such a lucky position. LLMs help automate the tedium out of their job, and hopefully, have a bit more extra energy to make a better system within their immediate locus of control.

it's to do with skill, not position and I don't think that was about luck.

Re: The Economic Benefit of Refactoring

#130
post #19

The benefits go beyond reducing token consumption. Compact contexts also foster better reasoning, enable intelligence across more layers if you can load them in a single context, and writing software to enable this, results in more correct software, software that _generalizes_, that has higher probability of being correct not just for tested cases, but for the interpolations and extrapolations of these cases. Refacto…

> It's all about reducing the entropy of your code In all corners of our world and the universe at large, reducing entropy in anything can be thought of as “building.”

All I heard was "compression is intelligence"
Post reply on HN