A good Dev in the situation you mention will design the solution needed now not the one you hope for later.
Maintainability is one of the most important if not the most important goal when programming. If a dev only designs a solution that fits for exactly the current situation but doesn’t allow any changes, it’s not a good dev.
But yeah, if you start small, a solution that’s made for that is preferable. You can still refactor things when you get magnitudes larger and have the budget.
The tricky thing about software development is this balance: you don’t want to hobble your system by designing only for today, because that could waste a whole lot of time later when needs change, but you also mustn’t paralyze the project by designing for all possible tomorrows. Finding a middle path is the art, and the only proof that you got it somewhat right is that things get done with relatively few crises.
Microservice from the start may be a lot of overhead, but it should at least be made with that scalability in mind. In practice to me, that just means simple things like make sure you can configure it via environment vars, run it out of docker compose or something because you need to be able install it on all your dev systems and your prod server. That basic setup will let you scale if/when you need to, and doesn’t add anything extra when planned from the start.
Allocating infrastructure on a cloud service with auto scaling is the hard part imo. But making the app support the environment from the start isn’t as hard.
Often a simple solution is the most maintainable solution. In my experience, the code that’s most difficult to maintain are often made by devs who tried to plan ahead. The code turns over engineered to allow for stuff that never materialized.
You evidently haven’t met my colleagues. There are always people who go for the quickest hack despite the trouble it stores up for later, and they’re usually encouraged by management.
Maintainability is one of the most important if not the most important goal when programming. If a dev only designs a solution that fits for exactly the current situation but doesn’t allow any changes, it’s not a good dev.
But yeah, if you start small, a solution that’s made for that is preferable. You can still refactor things when you get magnitudes larger and have the budget.
The tricky thing about software development is this balance: you don’t want to hobble your system by designing only for today, because that could waste a whole lot of time later when needs change, but you also mustn’t paralyze the project by designing for all possible tomorrows. Finding a middle path is the art, and the only proof that you got it somewhat right is that things get done with relatively few crises.
Microservice from the start may be a lot of overhead, but it should at least be made with that scalability in mind. In practice to me, that just means simple things like make sure you can configure it via environment vars, run it out of docker compose or something because you need to be able install it on all your dev systems and your prod server. That basic setup will let you scale if/when you need to, and doesn’t add anything extra when planned from the start.
Allocating infrastructure on a cloud service with auto scaling is the hard part imo. But making the app support the environment from the start isn’t as hard.
Often a simple solution is the most maintainable solution. In my experience, the code that’s most difficult to maintain are often made by devs who tried to plan ahead. The code turns over engineered to allow for stuff that never materialized.
I don’t think anybody is arguing this. Nobody (in my decade-plus in this industry) actively codes in a way to not allow any changes.
You evidently haven’t met my colleagues. There are always people who go for the quickest hack despite the trouble it stores up for later, and they’re usually encouraged by management.