I think this varies hugely on what level of the stack you're operating at.
At the front-end, redesign is relatively cheap, so the ideal way of building things is to be very "lean", and build the minimum possible. If you need to build something more, the old can usually be thrown away without penalty if that's the quickest path.
As we descend the stack, the cost of change increases - so we need more care in the work we do, and there's more "passive provisioning", where we deliberately build gaps for future functionality - and sometimes actually build the future functionality since it's easier than just leaving a gap.
Often, old architectures and API points have to live in the system, and be maintained, for significant amounts of time afterward - for support of mobile apps etc.
Infrastructure is even worse - changing infrastructure architecture can be time-consuming and risky. It's best to get that right first time.
In the worst case, standards development, we're trying to build the design itself, and we're stuck with that for years, if not longer.
We often try to minimize the cost of failure in our professional - "Lean", "Agile", and "MVP" all derive from this. We also, of course, have to minimize the cost of success.
Over-engineering isn't simply doing more engineering than is needed; it's doing more effort than the cost of success warrants.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I think this varies hugely on what level of the stack you're operating at.
At the front-end, redesign is relatively cheap, so the ideal way of building things is to be very "lean", and build the minimum possible. If you need to build something more, the old can usually be thrown away without penalty if that's the quickest path.
As we descend the stack, the cost of change increases - so we need more care in the work we do, and there's more "passive provisioning", where we deliberately build gaps for future functionality - and sometimes actually build the future functionality since it's easier than just leaving a gap.
Often, old architectures and API points have to live in the system, and be maintained, for significant amounts of time afterward - for support of mobile apps etc.
Infrastructure is even worse - changing infrastructure architecture can be time-consuming and risky. It's best to get that right first time.
In the worst case, standards development, we're trying to build the design itself, and we're stuck with that for years, if not longer.
We often try to minimize the cost of failure in our professional - "Lean", "Agile", and "MVP" all derive from this. We also, of course, have to minimize the cost of success.
Over-engineering isn't simply doing more engineering than is needed; it's doing more effort than the cost of success warrants.