The other angle is the majority of Devs are just… Not good…
A good Dev in the situation you mention will design the solution needed now not the one you hope for later.
I’m saying this as someone who has been mired in scope creep and over engineering solutions many times in my life because “what if 5000 people need to use it at once?!”
In most cases all you need is a database, a single thread and a simple API. Build it and then as the problems come grow with them. Try to take into account issues of scale but realize you can’t and shouldn’t solve every scenario because there are too many variables which may never exist.
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.
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.
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.
The other angle is the majority of Devs are just… Not good…
A good Dev in the situation you mention will design the solution needed now not the one you hope for later.
I’m saying this as someone who has been mired in scope creep and over engineering solutions many times in my life because “what if 5000 people need to use it at once?!”
In most cases all you need is a database, a single thread and a simple API. Build it and then as the problems come grow with them. Try to take into account issues of scale but realize you can’t and shouldn’t solve every scenario because there are too many variables which may never exist.
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.
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.
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.