121–130 of 375 posts
No it's not. This has always been a needlessly iconoclastic rather than sensible suggestion. At the very least it is not once you're working at the wrong kind of scale. Once you have an awkward number of customers (more than five and less than a hundred), maintaining duplicated code that should have been abstracted and modularised will only seem cheap if you don't mind that you burn through even junior employees at a…
Earlier quoted context omitted.
> I agree that LLMs are naturally anti abstraction machines.. I'm often trying to find way to reverse that. I am a bit of an LLM cynic but I am trying to learn it all, and I have to say I have spent most time trying to work out: how do you explain how a brown-field codebase actually works, in such a way that the LLM won't pervert it through misunderstanding. It does encourage you towards the "conventional" coding sta…
They don’t have a useful belief system, one of the rookie mistakes of using LLMs is asking them what you “should” do
A story I like is that in the now lost era of handwriting recognition on PDAs, Jef Raskin concluded that the easiest way to solve the problem was to change handwriting so as to meet the algorithm in the middle.
That is, to find a noticeable simplification of handwriting that people could learn quickly and that eliminated hard-to-process quirks.
I feel I am there with the LLM at the moment, trying to work out what the common ground is.
No it's not. This has always been a needlessly iconoclastic rather than sensible suggestion. At the very least it is not once you're working at the wrong kind of scale. Once you have an awkward number of customers (more than five and less than a hundred), maintaining duplicated code that should have been abstracted and modularised will only seem cheap if you don't mind that you burn through even junior employees at a…
The key lesson is that duplicate code is not necessarily "code duplication" - it was always really about abstraction duplication. If two unrelated variables happen to momentarily share a value, it doesn't mean that value should be made common between them, they are fundamentally different things. It would be a confusing lie and error-prone if the code implied they were the same and that efforts should be made for the…
Earlier quoted context omitted.
In your mind, what's the cost of the wrong abstraction?
The major risk/cost is breakage if you must change it but cannot maintain its whole surface even with a shim, right? But any abstraction ends up with a signature and a name that can quickly be found in code. The risk of a long-lived duplication losing its shape and being hard to find is much greater. Especially if the code is going through multiple hands. I once had to pick up a project — a working, fully functional…
Earlier quoted context omitted.
> Maintaining the wrong abstraction, or, god help, abstractions, would be even worse. Hard disagree. When you've had to chase through a change in untold and actually unknown numbers of duplications of code in different permutations and fix them because they are all on fire simultaneously, you'd disagree too. A bad abstraction would at least have had one fire in one place.
> A bad abstraction would at least have had one fire in one place. On the contrary: that's precisely what a bad abstraction would not offer. Instead it would spread its assumptions to different parts of the system, as every caller, sub-service, etc. would have to change shape to fit in that abstraction's box, however unnatural it is (and we know it would be unnatural, because we already said it's a bad abstraction).…
But so does duplication, in practice, and it diverges more as it does.
Earlier quoted context omitted.
The major risk/cost is breakage if you must change it but cannot maintain its whole surface even with a shim, right? But any abstraction ends up with a signature and a name that can quickly be found in code. The risk of a long-lived duplication losing its shape and being hard to find is much greater. Especially if the code is going through multiple hands. I once had to pick up a project — a working, fully functional…
I am confused by this comment. The root problem was the wrong abstraction was implemented. Then it was duplicated. Had there been no abstraction, it would not have been duplicated so readily? Am I missing something?
Also I’ve seen the kind of codebase that seems to be LZW packed due to the sheer desire to DRY everything out. Not pleasant thing, by the time you goto 10 layers deep on some “helper” function you forgot why you in there.
Earlier quoted context omitted.
At work there’s been a huge number of duplication in the start of the company and no solid abstraction. So no tests as well. We introduced tests in the current architecture but rewriting code has a huge cost to make sure there is no regression. When we talk about a saas it’s non-trivial with many customers relying on this tool daily as part of their workflow, regressions because of rewrite could be really painful for…
"It’s hard to find a good balance and it depends on the kind of business and scale of project". Exactly. The abstraction purists are not working in the messy, dead line driven real world.
Earlier quoted context omitted.
Hardly iconoclastic, it's a very sensible suggestion. It would be iconoclastic if the common sense basic approach would be to start with abstraction. It's not, the common sense default is to write possibly duplicate behavior until you actually discover several cases to abstract away, until you bevalop a sensible idea of which functionality unites them and which doesn't carry over all of them. > Once you have an awkwa…
Yeah, "Write Everything Twice" is a pretty common and sensible direction for any codebase
Write everything twice quickly becomes write everything 4 times once a new change appears, just as quickly as it becomes write everything 8 times, and so on.
I'm afraid there's no sensible soundbite developers can follow blindly.