Where I work developers are always telling me that "I added this just in case for the future" or "I think it's a good idea to do this because they'll probably want it some day". I think it's great that they're proactive in trying to anticipate future changes but I can't help thinking that it's unnecessary and risks writing code that may never be needed and therefore unproductive (I also think that some developers just want to try out something new for the sake of it). Are the arguments for future proofing invalid if you just write good, clean organised code?
Well first of all, there are some things that need clarification:


Future proofing is not adding stuff.
Future proofing is making sure you can easily add code/features without breaking existing functionality.


This means is that writing "future proof" code, is ensuring that the code is written in a loose coupled manner, sufficiently abstract, but also code that does not completely hide abstraction levels, so there's always a way to go to the lower abstraction levels if necessary.

Writing future proof code is an art by itself and is tightly coupled with SOLID practices for component versioning, separation of concerns, layering and abstractness of functionality. Future proofing has nothing to do with adding features ahead of time, but with making sure you can add features in the future in a non breaking manner, through the good design of existing code/libraries.

My 2c
