4 ms·

> Just stating, 'don't look further than the problem you are required to solve' is not an excellent general rule. It's still pretty good though; I think the on

> Just stating, 'don't look further than the problem you are required to solve' is not an excellent general rule. It's still pretty good though; I think the only better formulation is "only implement a general solution if it's _simpler_ than the particular/specialized solution". Sometimes, that is indeed the case - but it's pretty rare. So if you want to keep things simple, "don't generalize until you have 3 examples" is a pretty solid rule-of-thumb.

psychoslave 2y ago
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).
vrighter 2y ago
unless that lack of (intentional) lack of foresight by my superiors endud up with us having to rewrite a particular feature several times, over several years and it still doesn't work with acceptable performance, because it had to be shoehorned in later because we were shut down every time we said "but this is gonna make X impossible later!"
- t43562 2y ago
  There you have the gambling, the risk, the reason why programming isn't mechanical. One has to use judgement. Some generalisations are quite cheap, others very costly. It's always worth using the cheap ones and very important to use the expensive ones carefully. e.g. Use a named constant rather than a literal - that's hardly ever a bad generalisation...or making repeated code into functions. OTOH, writing all your code in e.g. asynchronous python on the assumption that you might need it to be async next year....that's an expensive effort which may never ultimately be justified. You have to be fairly sure that you will want it. It's also worthwhile to use languages that support change. So you can tell yourself that upgrading your code won't be an impossible pain in future. C++ is not one of those flexible languages so you feel pressure to get it right first time.
- virgilp 2y ago
  That's the thing, it might have been the right call. Take facebook: perhaps if you were on the original engineering team, you could've made the (correct) call that "developing this thing in php won't scale to billions of users! This is the wrong architecture!". And no doubt, a lot of hacks needed to be done, because it wasn't written "correctly" the first time. On the other hand, if you had written it for 1 billion users from the start, chances are that it wouldn't have ever surpassed 1000k users. And that's a much worse problem to have. --- To take it to your situation - perhaps the leaders really were incompetent; but also, perhaps if you spent more time to do it "right" earlier, the entire project would've been killed. It's hard to know what was the right call.... at least, the project is still alive, so the original call might not have been disastrous.
  - vrighter 2y ago

psychoslave 2y ago

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).

vrighter 2y ago

unless that lack of (intentional) lack of foresight by my superiors endud up with us having to rewrite a particular feature several times, over several years and it still doesn't work with acceptable performance, because it had to be shoehorned in later because we were shut down every time we said "but this is gonna make X impossible later!"

t43562 2y ago
There you have the gambling, the risk, the reason why programming isn't mechanical. One has to use judgement. Some generalisations are quite cheap, others very costly. It's always worth using the cheap ones and very important to use the expensive ones carefully. e.g. Use a named constant rather than a literal - that's hardly ever a bad generalisation...or making repeated code into functions. OTOH, writing all your code in e.g. asynchronous python on the assumption that you might need it to be async next year....that's an expensive effort which may never ultimately be justified. You have to be fairly sure that you will want it. It's also worthwhile to use languages that support change. So you can tell yourself that upgrading your code won't be an impossible pain in future. C++ is not one of those flexible languages so you feel pressure to get it right first time.
virgilp 2y ago
That's the thing, it might have been the right call. Take facebook: perhaps if you were on the original engineering team, you could've made the (correct) call that "developing this thing in php won't scale to billions of users! This is the wrong architecture!". And no doubt, a lot of hacks needed to be done, because it wasn't written "correctly" the first time. On the other hand, if you had written it for 1 billion users from the start, chances are that it wouldn't have ever surpassed 1000k users. And that's a much worse problem to have. --- To take it to your situation - perhaps the leaders really were incompetent; but also, perhaps if you spent more time to do it "right" earlier, the entire project would've been killed. It's hard to know what was the right call.... at least, the project is still alive, so the original call might not have been disastrous.
- vrighter 2y ago