One Way Smart Developers Make Bad Strategic Decisions

>> That's just flat wrong. A global solution can solve global concerns and also allow for local conditions.

So lets rephrase that. A global solution that ignores local conditions will have problems and will likely fail.

Past a certain level of complexity, that's no longer true.

_Seeing Like a State_ is a great introduction to this, but I think Carol Sanford's work goes much more into detail. The main thing with the high-modernist view that James Scott was critiquing is that it comes from what Sanford would call the Machine World View. This is where the entire system can be understood by how all of its parts interact. This view breaks down at a certain level of complexity, of which James Scott's book is rife with examples.

Sanford then proposes a worldview she calls the Living Systems World View. Such a system is capable of self-healing and regenerating (such as ecologies, watersheds, communities, polities), and changing on its own. In such a system, you don't affect changes by using direct actions like you do with machines. You use indirect actions.

Kubernetes is a great example. If you're trying to map how everything work together, it can become very complex. I've met smart people who have trouble grasping just how Horizontal Pod Autoscaling works, let alone understand its operational characteristics in live environments. Furthermore, it can be disconcerting to be troubleshooting something and then have the HPA reverse changes you are trying to make ... if you are viewing this through the Machine World View. But viewed through Living Systems World View, it bears many similarities to cultivating a garden. Every living thing is going to grow on its own, and you cannot control for every single variable or conditions.

For similar ideas (which I won't go into detail), there is Christopher Alexander's ideas on Living Architecture. He is a building architect that greatly influenced how people think about Object Oriented Programming (http://www.patternlanguage.com/archive/ieee.html) and Human-Computer Interface design (what the startup world uses to great affect in product design).

Another is the Cynefin framework (https://en.wikipedia.org/wiki/Cynefin_framework). Cynefin identifies different domains -- Simple, Complicated, Complex, and Chaos. Engineers are used to working in the Complicated domain, but when the level of complexity phase-shifts into the Complex domain, the strategies and ways of problem-solving that engineers are used to, will no longer work. This includes clinging to the idea that for any given problem, there is a global solution which will satisfy all local conditions.

HTTP; TCP; json; xml: all standardize pretty well. Want to standardize your micro services on nginx with data in json? It will work swimmingly and save time because it is one less decision to be made, and overtime everyone will become familiar with how nginx is setup. Standardizing on what json libs to use so that everyone can dig into the json marshalling code without a lot of head scratching would be another big win.

Trying to standardize people never works because they want to do things their own way and view whatever standard you try to impose as wrong.

Junior devs just repeat themselves because they don't know better.

Middle devs rush into an incomplete abstraction by overzealously not-repeating-themselves.

Senior devs just repeat themselves because they know they don't understand what it would take to abstract out the solution.

Like everything... "It Depends". Don't Repeat Yourself Too Much.