Easy To Change – The principle to guide engineering
The principle to guide engineering


I was preached and have been preaching OO style of programming
paradigm from since my college days and well into the early years of my
profession. Then FP became the new style (old became new?) and all OO
programming languages started to add more FP style constructs. Now we
see debates over why FP is superior over OO and should be used over
all cost claiming that OO is responsible for all the mess that we
created over the last 20 years or so. Now, I came to realize that it
is not this or that paradigm that is responsible for all the issues we
created. Rather, it is the blind adoption of them by us as
practitioners. Let us think about a minute what OO have given us when
we started to adopt it: The ability to structure, reuse and share code
across systems. Essentially, we were able to build/change information
systems faster and easier than ever before. However, it did not hold
up well against ETC principle with its humongous frameworks and so
called best practices. Now, FP is in its renaissance and being
preached as the savior at the cost of relegating OO to its
oblivion. OO is a great tool set in our arsenal for certain types of
problem domain and SmallTalk is an example of how it should be
practiced. FP is another excellent way of approaching to engineering
problem in that it encourages to treat systems as referential data
transformation pipeline. Does it inherently make the system easy to
change? Not really. We are quite capable of making a spaghetti mess
out of FP as much as we have done with OO. See a pattern here? ETC
principle grounds your choice of paradigm into its proper place: Is
x helping you to make changes easier? If not, then x most likely not
best route for you.



I can go on and on with arguing ETC be the test to pass for all of the
paradigms and even development approaches such as TDD, BDD and
DDD. For example, If your code is easy to change, it will most likely
be easy to test, maps most likely well with your domain and most
likely models use cases better. You can adopt any approach or
principles such as SOLID principle if you consistently ask yourself:
Does this really helps me to make changes easier? If it passes this
test, adopt it, if not avoid it.



It is not my intention to make you dogmatic about Easy To Change
(ETC) principle but rather to convince yourself to have one principle
to ground all other aspects of your engineering endeavors. Happy
engineering and never forget to have and share fun coding!

