O’Reilly are publishing a new book “97 Things Every Software Architect Should Know”. This caught my attention for a variety of reasons. One is an interest in trying to get to the bottom of what the issues commonly labelled as “software architecture” are really all about! Another reason is that there are a couple of contributions from Kevlin Henney, with whom I have worked and who frequently comes up with a “different take” on any situation.
In one of his two contributions to this book, “Simplicity Before Generality, Use Before Reuse”, he argues for guarding against over-generalisation because it leads to unnecessarily complex designs which deal with cases which are probably imaginary anyway; rather, he suggests favouring simpler solutions which are known to satisfy specific cases.
This prompted me to pen an article on Alternative priorities when designing which proposes a converse view.
A question seems to arise, and one way of putting it seems to be: should we start with solutions that are general enough but overly complex and work on reducing their complexity? Or should we start with solutions that are too simple and not general enough and work on increasingly their complexity until they are general enough.
My personal instinct tends to be characterised by “interface before implementation” and “right first and fast later”, which seem to imply the former. But Kevlin seems to be arguing for the latter, and I must admit that this was worked for me too. This has already fulfilled my expectation of a “different take”!
What works for you?