4 ms·

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 an

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
  it wasn't a feature we "might need in the future" This was a critical piece of functionality. It was backup software, with deduplication. The feature in question was the ability to delete old backups. We were forced to release without it and then rush to implement something before customers ran out of disk space and started asking for refunds

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
it wasn't a feature we "might need in the future" This was a critical piece of functionality. It was backup software, with deduplication. The feature in question was the ability to delete old backups. We were forced to release without it and then rush to implement something before customers ran out of disk space and started asking for refunds