DEV Community

Discussion on: ⏳ Is Future Proofing just Overengineering? 🤹

sent2null profile image
David Saintloth • Edited on

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'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 never written.

adam_cyclones profile image
Adam Crockett Author

I can fully respect this position, it is one that I share. Thank you for chiming in.