Martin Fowler has a gift of writing books that read like an old friend. I don’t know what it is, but when I read them I feel I get educated, not lambasted. While reading Refactoring: Improving the Design of Existing Code I came upon a discussion of the dangers of excessive flexibility we tend to put in our design. This little chapter struck a cord with me because I recognized something I’ve been guilty of myself.
Martin says:
“If you don’t refactor, there is a lot of pressure in getting […] upfront design right. The sense is that any changes to the design later are going to be expensive. Thus you put more time and effort into the upfront design to avoid the need for such changes.
With refactoring the emphasis changes. You still do upfront design, but now you don’t try to find the solution. Instead all you want is a reasonable solution.”
Too Much Flexibility
Further, he talks about building solutions that are too flexible: in the upfront design you try to foresee every situation when your product needs to bend over backwards, and you code it accordingly for ultimate flexibility. This flexibility comes at a cost.
Martin’s killer point is:
All this flexibility is not needed. Some of it is, but it’s impossible to predict which pieces those are. To gain flexibility, you are forced to put in a lot more flexibility than you actually need. (Emphasis added)
A couple of years ago, when I started developing our product, Customer Feedback Center, I wanted a lot of useful stuff in it, including remoting. In most of my decisions I was right on the money, but remoting was an unnecessary drag for a couple of years, until I realized that my prediction of its usefulness in our product didn’t come true. Remember, I was under the spell of the architectural guidance of the day, but dust has settled down since then.
This realization came while reading another great book by Martin Fowler, Patterns of Enterprise Application Architecture:
“My First Law of Distributed Object Design: Don’t distribute your objects. […]
As you design your system you need to limit your distribution boundaries as much as possible, but where you have them you need to take them into account.”
I went back and removed “distribution boundaries” because they, clearly, were the result of over-engineering.
Conclusion
I’ll wrap this up with yet another quote from Refactoring: “You build the simplest thing that can possibly work. As for the flexible, complex design, most of the time you aren’t going to need it.”
