4 ms·

But the main issue with that kind of remarks is that we are not omniscient demiurges. If we don’t try to implement two approaches, then we won’t be able to judg

But the main issue with that kind of remarks is that we are not omniscient demiurges. If we don’t try to implement two approaches, then we won’t be able to judge based on actual facts and metrics. If we already did that in the past often enough, sure we can gain some intuition on what will be the actual outcomes of the tradeoff we retain. But paying the price to build such an expertise is also a tradeoff. In particular we might desire to provide the most sound and solid solution from a grand master quality level. But if the whole market is already in the hand of a few players that went with the old card of "occupy the territory first and (possibly) consider quality later", our grandiose art will be also a path to starvation.

virgilp 2y ago
> our grandiose art will be also a path to starvation. That's what I'm saying, that in general the "grandiose art" _is_ a path to starvation, in a lot of business software at least. Because the actual (eventual) requirements are often unknowable at the start, and the initial assumptions are often invalid/false. So if you build your grandiose architecture based on wrong initial assumptions, it'll still lead to a subpar product even if the architecture was perfectly correct (given said assumptions). It's better to approach it with the idea that you're not writing code that needs to run 1 more than e.g. 1 year (but, you ARE writing code that you might need to maintain next year! that's a subtle but important difference. You write code to move fast now - not to enable you to move fast 1 year later; BUT, at the same time you write code that won't slow you down horrendously, in case you can no longer delete it 1 year later).