Last week I stumbled upon a nice quote from Corey Quinn that I shared via Twitter:

In the previous part of this series I discussed why reusability is a false friend in distributed systems and thus should not be used to sell distributed architectural approaches. Additionally, I discussed the difference between “usable” and “reusable” assets and why you should strive for “usability” in distributed approaches like, e.g., microservices.

In the second part of this blog series about reusability I discussed the costs of making a software asset reusable. It turned out that creating an actually reusable asset means multiple times the costs and efforts compared to creating the same asset just for a single purpose.

In the first part of this blog series about reusability I discussed why all the reusability ideas break that root in the physical world and that are based on the idea you can save money in the production process by using reusable/standardized parts. We have seen that the actual production process in IT is already practically optimal. Thus, if reusability can help to save time, costs and efforts at all, it can only do so in the design process, which…

After several posts discussing different aspects of IT as a whole, I would like to start discussing another thread of thinking: software architecture. This is a huge topic and I pondered for quite a while where to start. Finally, I decided to start with debunking the long-lived architectural myth of reusability because this makes it easier to understand some of the ideas that I will discuss in later posts.