Addressing Institutional Fetishism with SOLID Principles

Recently I encountered a video on YouTube entitled INSTUTIONAL FETISHISM: Why “There Is No Alternative” Feels True, which discusses Roberto Unger’s notion of “institutional fetishism”, whereby alternatives to presently existing institutions are not considered because those institutions have come to represent the thing itself. Something similar happens with genericized trademarks; a brand name becomes so ubiquitous that its name is synonymous with the product. We Google rather than use a search engine, use Band-Aids rather than adhesive bandages, and apply Chapstick not lip balm. Unger theorizes that this is happening when representative democracy as practiced in the United States, or the particular form of market economics practiced by the US, UK, and EU are taken to be what democracy and market economics are period. When this happens, change is only possible insofar as it reproduces existing conditions (ie not really possible at all).

I don’t think I will ever express the stereotypical tech bro attitude that there’s a technological solution to every problem, and indeed many attempts by tech companies at “disruption” are examples of institutional fetishism at work, as evidenced by the fact that a common joke about tech industry solutions takes the form “Big Tech invented {already existing thing} but worse”. But if there is an overlap between computer science and political programs, it is the need to design systems that are flexible, maintainable, and responsive to change. For that reason, the descriptions of institutional fetishism brought to my mind my experiences with tight coupling and the solutions found in SOLID programming principles.

Tight versus Loose Coupling

A desirable feature of computer programs and systems is loose coupling, which is basically when parts of that system have breakable relationships. An example that comes up in my work mentoring junior developers is handling something like saving files.

What they’ll often do is start by simply writing data directly to the filesystem. Now file handling is synonymous with writing data to disk. Works great! Until they try to run the same code in a cloud environment where they either don’t have access to the filesystem, or they do but it’s temporary and everything is deleted when their code is done running.

Next they might rewrite their code to use a service like Amazon S3. Works great! All they had to do was create an AWS account, provision the S3 bucket, add that configuration to the project, document how to configure the project for their teammates, configure all remote and test environments… and all their new and existing colleagues can now look forward to doing the same when they start working with this code and never being able to work offline.

What could we do to make this more flexible?

Interfaces

Instead of immediately jumping into implementing a file handler, we could start by defining an interface. An interface would describe what information a FileHandler would need for it to be created, all the things it could do, and the outputs it produces. In our example, all file handlers might need to know the name of a folder where they should save files, and have one save() method that takes a filename and data and returns the absolute path to the saved file as a string.

Why would this be good? We might start by implementing a FilesystemFileHandler that simply saves the data to disk. And we could also create a more complex AWSFileHandler that requires additional configuration and saves data to the cloud. But everywhere in our application where a FileHandler is needed, it makes no difference what kind of FileHandler is being used; they can all save() data and will all tell you where that data was saved. We could configure our app to use the local implementation during development and testing, and configure our remote environments to use the implementation backed by AWS, without any of the code that depends on file saving knowing the difference.

This design by contract methodology allows a lot of flexibility for change without impacting the broader system, and separating concrete implementations from their interfaces - the antithesis of institutional fetishism - is what makes that possible.

Institutional Interfaces

Mentally defeating institutional fetishism requires the same willingness to reduce those institutions to their expected inputs, functions, and outputs. An example from the video is reducing democracy to being collective self-governance. American style democracy is an implementation, and governing via proposals approved by a random sample of adult citizens would be too.

Define what’s minimally acceptable for a healthcare, transportation, or agricultural systems in the abstract, and what alternatives become possible? Can we string together a more resilient society when the relationships between those systems are easier to break?