The first part of the article describes the common situation where we see similarities across projects and effort being duplicated, apparently unnecessarily. T

The first part of the article describes the common situation where we see similarities across projects and effort being duplicated, apparently unnecessarily. To improve understanding and efficiency, we come up with proposals that involve some kind of standardization, such as a shared library abstracting a service. My team has recently embarked on such an effort, and I was really hoping for a new take on how to avoid the various pitfalls involved in attempting this kind of standardization. Obviously, central planning works quite well for certain things and, just as obviously, it hasn't worked well for other things. In most situations, it seems that a combination of planning + flexibility works best. Further, what works or doesn't work for nation-states isn't particularly applicable to software architecture. The analogy feels quite tortured to me. As to the example given in the article regarding trees, one could just as easily choose an example from modern agriculture where "central planning" seems to work quite well. In the end, I feel like the article just boils down to: "Make sure you understand the problem domain and the cost of large scale change before you spend a lot of time and effort making said changes."