blog

In the previous post, I mentioned the second law of program evolution that Lehman described in his paper Programs, life cycles, and laws of software evolution

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…