Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Economic Benefit of Refactoring

martinfowler.com

Post reply on HN
Print view View original

101–110 of 132 posts

Re: The Economic Benefit of Refactoring

#101

Post by HappMacDonald »

rocky_raccoon wrote: post #94

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'm curious how heavily you have test suites built up as guardrails while doing this, to prevent regressions and such?

Re: The Economic Benefit of Refactoring

#102

Post by dash2 »

sltr wrote: post #5

the punchline: "Refactoring reduces token consumption" I appreciate the effort to quantify the benefit rather than pontificate. It's worth mentioning Martin Fowler wrote a whole book on refactoring [1], in which he states, "to refactor, the essential precondition is [...] solid tests", which I think is the real benefit here, AI or not. Good tests protect against regressions, whether human or robot. They also help enc…

I think the real punchline was that the value saved was on the order of cents!

> Every single change that touches the data access layer from this point forward now costs significantly less.

> How much of a saving? Assuming Sonnet 5 pricing at the time of writing of $3/MTok, 39.7 cents.

Now consider OpenAI's price drop, and open models, and consider that in the long run tokens will get cheaper. And think that the refactor needs to be human guided at a price of what for a senior developer - $100/hour?

Re: The Economic Benefit of Refactoring

#103

Post by mattmanser »

HappMacDonald wrote: post #101
rocky_raccoon wrote: post #94

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'm curious how heavily you have test suites built up as guardrails while doing this, to prevent regressions and such?

I have often done huge refactors over the last 20 years on systems where there are none. It's very satisfying turning a 1,000 line class file into 100 lines.

But all my refactors have been in statically typed languages.

To speculate on the reason why, which the GP asked, I think perhaps it is two things. It's the same satisfaction from tidying a room or your workbench. But it's also slightly narcissistic unfortunately. I think you've shown you're better than the other programmers. Much, much, better when you end up with massive reductions in TLOC.

And with tests, the irony is that the resulting code is often so much easier to reason about, you start spotting really obvious bad assumptions in the original implementation.

It's one of the reasons I've always been fairly skeptical about the true value of unit tests (integration, I get). That and the fact that projects I've worked on that did have unit tests catch like 1 bug a year. Maybe it's just the size of systems I traditionally work on (smaller teams, or even 1 person teams, so man-years worth of effort rather than decades or centuries).

Re: The Economic Benefit of Refactoring

#104

Post by benrutter »

Tangent, but I have a theory that refactoring is one of the best symptoms of a healthy dev team.

It's partly that refactors themselves have benefits, but I think more that the benefits to refactoring aren't visible to something like product-owners, feature tickets, etc.

If teams are refactoring to ensure the health of the overall software, it's a tell-tale sign that developers are happy making recommendations for good software, and that those recommendations are being taken seriously.

I think Martin Folwer might have actually coined the term "software rot" - either way, as an issue it happens most severely when a team either aren't motivated or empowered to build their vision of high quality software. When a team can follow their judgement of excellence, that's usually a great sign!

(and yes, obviously this can go to far, there are probably some teams who rewrote all their stuff in Ruby then Node then Rust and now something else to be "agent native", but in the coorporate world, I see a lot less of this than teams who just don't feel like they have permission to improve things)

Re: The Economic Benefit of Refactoring

#105

Post by gga »

nycticorax wrote: post #75

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.

Re: The Economic Benefit of Refactoring

#106

Post by gga »

jmartrican wrote: post #71

The author said that Claude was not good at refactoring. But the author was using Sonnet 5. I supect Opus 5 would have done a lot better at refactoring. It would have come up with a multstep approach, i suspect.

I used Opus 4.8 to create the refactoring plans. I converted token savings using Sonnet 5 pricing at the time of writing as I'd expect to use that for more 'straightforward' feature additions.

Re: The Economic Benefit of Refactoring

#107

Post by movpasd »

rocky_raccoon wrote: post #94

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…

Me as well. One of my formative experiences was reading Refactoring (Fowler). At the time I felt skeptical that it could make a difference --- I had mostly written scientific/research code at this point. I decided as an experiment to apply it to a dissatisfaction I had with the structure of a codebase and it was a revelation. It really made it really concrete what people meant by "a codebase is a system", made me see code from a higher level, almost like a continuous tissue or web you could pull and prod.

It's quite sad to think this experience might be on its way out, and it really highlights that "junior problem" from AI. There is just no way around diving in to get an intuition for things. Naur warned us of this 40 years ago but the lesson never seems to get learned.

Re: The Economic Benefit of Refactoring

#109

Post by sqemo »

rocky_raccoon wrote: post #94

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 enjoy studying different refactoring patterns and real-world examples.

Re: The Economic Benefit of Refactoring

#110

Post by vogelke »

rocky_raccoon wrote: post #94

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.

Post reply on HN