4 ms·
> Most projects know pretty well where they will be in one or two years I dispute that that is true. They may have a vague idea of a goal, but that's not appl
by gnaritas 11y ago
> Most projects know pretty well where they will be in one or two years
I dispute that that is true. They may have a vague idea of a goal, but that's not applicable at the code level in general.
> Based on that knowledge you can make reasonable decisions and trade-offs now.
We aren't talking about making decisions, we're talking about stubbing out code for future needs, an entirely different thing. Nothing wrong with making reasonable decisions, but there is something wrong with stubbing out code you don't need because you think you'll need it later; if you need it later, add it later. It'll cost the same as adding it now. If you think it's going to cost more later, then revisit your architecture because it shouldn't. The implicit argument for adding it now is that's it's cheaper to add now than later, I'm saying that's nearly always a bunk argument.
> However, I admire your ability to write code without any forethought now that can be used perfectly in whatever form it will be needed later.
That's not what I said; the cost of change should be the same later as now. That doesn't mean you won't have to make a change, it just means it shouldn't be harder to add later than to add now.
- maxxxxx 11y ago"We aren't talking about making decisions" I was talking about decisions and not writing code and was pretty clear about that.
- gnaritas 11y agoNo, you weren't, and I quote > That could mean a simple API wrapper that can later on be optimized That's code. That's what I'm responding to, you insulted those who believe in not writing code before it's necessary, called them sad, and now you want to deny the very thing being replied to? Really? Forget it, you don't know how to discuss something.
- Piskvorrr 11y ago> the cost of change should be the same later as now That's patently false in any code I've seen; and saying "well make it so, can't be so hard" is just proof by handwaving.
- gnaritas 11y agoAnd claiming you must stub it out now because it might be needed later is straight up pulling it out of your ass guessing. Beyond that, I was very clear, if the cost of change is more later, you're doing something terribly wrong and trying to cover it up by stubbing out features before they're needed to avoid the real problem that you write code badly in a way that makes stubbing out stuff ahead of time necessary. It's new code, so you can absolutely write it without extra scaffolding for "shit you might need later". If you don't need it now, you don't need it yet.