3 ms·

The "right" solution vs "right now" is a lifelong dilemma for developers. If you don't expect your project will have a long shelf life, it might be easier to ac

The "right" solution vs "right now" is a lifelong dilemma for developers. If you don't expect your project will have a long shelf life, it might be easier to accept parts in the stack that aren't going to scale. But if your project has prospects for the future, putting in the time to create a solid foundation will pay dividends when the moment comes to scale up. For some annoying reason though, we can't really predict the future and a lot of small, never-meant-for-greatness projects due pick up momentum and need to grow. Then you're in a world of pain. Hope for the best, prepare for the worst, I guess.

dec0dedab0de 4y ago
If you don't expect your project will have a long shelf life, it might be easier to accept parts in the stack that aren't going to scale. But if your project has prospects for the future, putting in the time to create a solid foundation will pay dividends when the moment comes to scale up. I have services that were supposed to last 3 months that are still running 6 years later, with a firedrill every 6-18 months when requirements change without warning. I've also spent months working on things that were meant to last years, that never made it to production because the product owner changed their mind. My general rule is to assume everything will last forever, and organize my code with maintainability and changes in mind. But also to deploy the simplest way possible and scale only when needed.
ryanbrunner 4y ago
For sure it's definitely not a simple question where the answer is "right now" all of the time, but my overall point is that at least with modern trends in development, we way overcorrect for "right". A couple of things that help me when considering this question: - Is it really a question of "right" vs. "right now"? Is there a genuine compromise with choosing the simpler option? In my experience there often isn't. Using server rendered HTML vs. a SPA for some types of applications isn't going to result in a poorer UX. Using a slower language might be fine forever if raw language execution speed isn't your bottleneck (it rarely is IMO). - Is it more expensive to do what's best for later later? I think this is especially relevant for dev ops questions. Moving to a Kubernetes setup is going to be just as expensive in the future as it is right now, so it's better to delay that cost for when you actually need it. - How likely is it that you're going to know what is going to require a more robust solution now? Do you know what the service boundaries of your microservices are going to be? Do you know which portions of your app are going to be scaling concerns?

dec0dedab0de 4y ago

If you don't expect your project will have a long shelf life, it might be easier to accept parts in the stack that aren't going to scale. But if your project has prospects for the future, putting in the time to create a solid foundation will pay dividends when the moment comes to scale up. I have services that were supposed to last 3 months that are still running 6 years later, with a firedrill every 6-18 months when requirements change without warning. I've also spent months working on things that were meant to last years, that never made it to production because the product owner changed their mind. My general rule is to assume everything will last forever, and organize my code with maintainability and changes in mind. But also to deploy the simplest way possible and scale only when needed.

ryanbrunner 4y ago

For sure it's definitely not a simple question where the answer is "right now" all of the time, but my overall point is that at least with modern trends in development, we way overcorrect for "right". A couple of things that help me when considering this question: - Is it really a question of "right" vs. "right now"? Is there a genuine compromise with choosing the simpler option? In my experience there often isn't. Using server rendered HTML vs. a SPA for some types of applications isn't going to result in a poorer UX. Using a slower language might be fine forever if raw language execution speed isn't your bottleneck (it rarely is IMO). - Is it more expensive to do what's best for later later? I think this is especially relevant for dev ops questions. Moving to a Kubernetes setup is going to be just as expensive in the future as it is right now, so it's better to delay that cost for when you actually need it. - How likely is it that you're going to know what is going to require a more robust solution now? Do you know what the service boundaries of your microservices are going to be? Do you know which portions of your app are going to be scaling concerns?