The underlying supposition about "future proofing" is that one anticipates a future need that is beyond the current one...the question is, is that assessment valid???
The natural growth dimensions of an application are pretty easy to identify and if one future proofs along those vectors then that additional robustness would be useful as the applications problem scope grows...however, if you chose incorrectly you can end up building classes or methods that will never be used (the old days of architects sitting high on a design horse over engineering for "future need" come to mind).
Today there is much less need for this type of engineering...we live in a very user centric and design driven development paradigm...where the data and features required by the users are what drives the constructs in the back end that make that happen...it's vastly more parsimonious and more importantly it TELLS YOU WHERE YOU NEED TO FUTURE PROOF.
The users preferences drive the development of things that satisfy those preferences and nothing else need even be considered as the User is God.
For some developers this reverse of the old ways of doing things may be confusing but it is the way it is...and the way it must be to ensure superfluous code for anticipated future needs that will never be executed ...is never written.
How’s it going, I'm a Adam, a Full-Stack Engineer, actively searching for work. I'm all about JavaScript. And Frontend but don't let that fool you - I've also got some serious Backend skills.
Location
City of Bath, UK 🇬🇧
Education
10 plus years* active enterprise development experience and a Fine art degree 🎨
The underlying supposition about "future proofing" is that one anticipates a future need that is beyond the current one...the question is, is that assessment valid???
The natural growth dimensions of an application are pretty easy to identify and if one future proofs along those vectors then that additional robustness would be useful as the applications problem scope grows...however, if you chose incorrectly you can end up building classes or methods that will never be used (the old days of architects sitting high on a design horse over engineering for "future need" come to mind).
Today there is much less need for this type of engineering...we live in a very user centric and design driven development paradigm...where the data and features required by the users are what drives the constructs in the back end that make that happen...it's vastly more parsimonious and more importantly it TELLS YOU WHERE YOU NEED TO FUTURE PROOF.
The users preferences drive the development of things that satisfy those preferences and nothing else need even be considered as the User is God.
For some developers this reverse of the old ways of doing things may be confusing but it is the way it is...and the way it must be to ensure superfluous code for anticipated future needs that will never be executed ...is never written.
I can fully respect this position, it is one that I share. Thank you for chiming in.