Re-use is the holy grail of IT: whenever a new architectural paradigm comes to IT town, “re-use” is one of the core arguments why to go for that paradigm. The business sales pitch typically goes like this: “Switching to <insert new paradigm here> will cost some money upfront but due to the re-use it enables it will soon pay back”.
I do not know about your experiences but I have never really seen it working the promised way. No matter if you look at Object-orientation, CORBA, Component-based architectures, EJB, SOA, you name it: re-use was accomplished to a lot smaller degree than promised, which meant that the promised business case never got realized. Additionally, very often brittle and tightly coupled systems emerged after a while that were very hard to change and operate, i.e., the business case started to turn into its opposite. But fortunately, at this point in time usually the next holy-grail paradigm showed up and the cycle started over again.
In short words: re-use based on any architectural paradigm never worked as promised, the promise was always broken.
And today? Currently, microservices are the paradigm de jour, and – of course again – re-use is the business case promise that accompanies it regularly. Will it work this time? Have we finally found the long promised silver bullet?
I do not know your opinion about it, but I am convinced that if we push for re-use in our microservice approaches, we will – once again – end up with a completely messed up architecture, including a very poor business case.
This leads to the question: Why is the promise of re-use broken?
There are several reasons why the re-use promise is broken. Here are my – probably incomplete – observations:
First of all, good reusability is expensive. Fred Brooks many years ago coined the “Rule of 9” for a re-usable component (where “component” here solely means the basic building block of re-use, no additional semantics attached to it). Based on his observations it took about three times the effort to design a component that can be re-used properly compared to a component that was just designed for simple use. This has a lot to do with the fact that it is very hard to isolate the right responsibility in a component and then to design a good API to offer the functionality to others. It takes a lot of brain-power and trial and error to come up with such a component.
Brooks also made the observation that it takes another factor of three to make the component ready for re-use, i.e., the required testing, hardening and documentation. Finally he stated that these two factors are independent, i.e., they do not sum up, they multiply. This 3 times 3 lead to the “Rule of 9”.
You might say that Fred Brooks was way too pessimistic with his statements and that we cannot compare software development in the early 70ies (when he made his statements) to software development today. And you may be right. Things have changed and might have become better (even though I have not seen any evidence for that). So, maybe a factor of 9 is too high today, maybe it is just 5 times the effort to turn a simple project result into a re-usable component, i.e., the additional struggling for the right responsibility encapsulation, good APIs, additional testing, documentation and hardening.
This means that you need a re-use of at least 5 times for a component that was made re-usable in order to amortize the investment, and you would need a lot higher re-use factor to justify the typical re-use business case, which claims that you do not only amortize your investment but save a lot of money over time.