> Q: Do you envision revisiting the same choices at a different stage of the product cycle?
Of course things might change, don't know what they will be though. I feel that we might end up writing some low level search software in Rust, though that is atleast few years down the line. It seems rust is default language for systems programming these days.
> Q: Do you think the tech stacks are snapshots in time (that can be easily transitioned from) or as commits (irreversible choices)?
I guess the intention of the question was "Should we spend time upfront deciding on the tech stack, because the choice is irreversible?" The answer is yes! Changing tech stack later is very very hard, and the initial choice impacts lots of things. Unless the motivation to change the stack is really strong and you have tons of resources to do it, your choice of stack will probably stick around.
Though, you can structure things in a way that you replace parts without impacting the whole. For example, you can write the backend service in a way that it doesn't know too much about which DB are we using so that you can replace it easily. There are cost to writing and maintaining these abstractions. My principle is to make it work and then after a little while make it better. Introducing too many abstractions too early boggs you down. And you end writing useless abstractions.
I really like the thought put into keeping things simple and "boring".
Q: Do you envision revisiting the same choices at a different stage of the product cycle?
Q: Do you think the tech stacks are snapshots in time (that can be easily transitioned from) or as commits (irreversible choices)?
> Q: Do you envision revisiting the same choices at a different stage of the product cycle?
Of course things might change, don't know what they will be though. I feel that we might end up writing some low level search software in Rust, though that is atleast few years down the line. It seems rust is default language for systems programming these days.
> Q: Do you think the tech stacks are snapshots in time (that can be easily transitioned from) or as commits (irreversible choices)?
I guess the intention of the question was "Should we spend time upfront deciding on the tech stack, because the choice is irreversible?" The answer is yes! Changing tech stack later is very very hard, and the initial choice impacts lots of things. Unless the motivation to change the stack is really strong and you have tons of resources to do it, your choice of stack will probably stick around.
Though, you can structure things in a way that you replace parts without impacting the whole. For example, you can write the backend service in a way that it doesn't know too much about which DB are we using so that you can replace it easily. There are cost to writing and maintaining these abstractions. My principle is to make it work and then after a little while make it better. Introducing too many abstractions too early boggs you down. And you end writing useless abstractions.