Skip to content
Home ยป Writing Software is a Political Act

Writing Software is a Political Act

Do you like a rabbit hole? Everyone likes a rabbit hole.

I went from Andrew Harmel-Law’s talk Power Structures and their Impact on Software to the idea that software is inherently political+ and found that Technology is Political in More Ways Than One.

To paraphrase that article, which itself paraphrases Langdom Winner’s 1980 paper “Do Artifacts Have Politics” we can view the technical world politically as follows:

  1. Firstly it can be deliberately, aggressively exclusionist. The barrier to entry is set deliberately too high to keep out people that we don’t want to work with.

2. Its form or default implementation benefits some group of people over another group of people.

3. A technology choice comes about because it’s compatible with existing technology. It’s a defacto choice.

4. A technology is exclusionist because it requires certain enabling conditions.

This is a completely reductionist approach but I want to rush to a conclusion. I want to get sense that all of these overlap or are various views which examine the same point of reasoning. We make choices because we can and we are doomed either to fail to take all views into account through accidental omission or because we just don’t care.

This in some ways reflects the talk that brought me to this conclusion. In Andrew Harmel-Law’s talk*, he posits some ways we can avoid dominant power structures or inherent bias and poor engineering in our solutions. These are for individuals and teams to have the:

  1. Freedom to Reorganise
  2. Freedom to Move (leave, or from team to team)
  3. Freedom to Disobey (a form of healthy Anarchism)

This makes me think that writing software is an inherently political act, and something which is deeply personal and hard to sometimes quantify.

Therefore can we ever truly depoliticise software development and should we even try? Perhaps rather than setting up guidelines and frameworks for behaviour, architecture or software development practice, we should just embrace the big ball of mud?

This aligns with my thoughts about the philosophy of architecture. If we can only ever know good architecture by stressing the pieces we build, surely we are all just learning by doing? Acceptance of our own and other’s shortcomings when it comes to writing systems and code seems to me the simplest form of expressing our work.

In other words, stay humble, keep learning and be nice.

* – also discovering Andrew Carmel-Law’s excellent post on the subject of Scaling the Practice of Architecture, Conversationally

+ – Nod to Richard Pope’s work and “Software is Politics”

Photo by Mymoon Humayun on Unsplash