[r-t] Definitions so far

[Mark Davies]

John Harrison writes,

> You design for current function but don't you try to future proof what you
> produce so if a small part of it needs changing the whole thing won't have
> to be ripped apart?

To an extent, for sure. But this really becomes part of good design for 
whatever your current requirements are. Modularisation helps break a 
problem down into smaller parts, as well as providing flexibility for 
the future. Similarly, parameterisation is part of "good code now" as 
much as "make change easy".

What you definitely *don't* try to do is "future proof" your code. That 
way lies madness, always.

Another point that can perhaps be learned from the world of software 
development is that it often turns out that the code that is most 
flexible and easy to change is the code that is small and simple, and 
doesn't try to be too clever.

MBD