[r-t] Definitions so far
mark at snowtiger.net
Sat Jan 17 22:18:26 UTC 2015
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.
More information about the ringing-theory