The world changes. Any application you build has to cope with change. Future-proofing is a frame of mind that equips your application with the flexibility to cope.
Good, clean design, modularity, separation of concepts, and good quality code, all make applications easy to change when the need arises. But future-proofing aims to reduce the need to change the application in the first place.
The biggest no-no I see, and have campaigned against endlessly, is where data is embedded directly in the code.
Some examples are obvious and clearly the result of short-sighted laziness. A programmer writes a routine to calculate tax, and sticks the tax rate right in the middle of the calculation. Why do that? You know taxes will change. The rate should be stored somewhere where it can be changed without having to delve into the code.
Better still, it should be something that a business user can change without involving application support at all.
Less obvious examples are more difficult to spot. The company name at the top of every screen and report, for example. Honestly, have companies never been know to change names? Make it a variable. It's just as easy. In fact, it's probably easier than typing the same thing over and over.
The real killers, though, are the constants that are so ingrained you don't even mention them in your design at all! For instance, what about all those monetary values with $ signs in front - are you sure that is fixed and forever? Try asking all those European businesses what fun they had when Francs and Deutschmarks and Lira gave way to the Euro.
My advice is to challenge any hard-coded value. Is it really fixed? Can you ever envisage a situation where it could change?
This is easily summed up as ... Constants are best regarded as variables.