This is the last free weekly issue, if you want access to the new Resilience Roundup community along with things like the podcast version, access to conference notes and analysis, and discussion group calls where you can ask questions, you can get a discount as an early adopter here. Either way you’ll still get free issues periodically and retain full access to the library of issues so far!
This is a bit of a different paper than I usually feature here, one by a sociologist, Susan Star,focused on life science and medicine. There’s a lot here that can help us as we thinking about and examine our systems. Thanks to Yvonne Lam for brining it to my attention, I was also fortunate enough to get to participate in a discussion she led on the paper!
Star looks at how infrastructure affects how people use tools and how assumptions become encoded into it which can be difficult to examine. Even what is defined as infrastructure can vary according to context and perspective.
Examining infrastructure
Deconstructing infrastructure or finding specific parts of infrastructure can be difficult because infrastructure tends to be glossed over in narrative or historical accounts.
This happen in our world of software too, perhaps less so if you consider your team an “infrastructure team,” but still occurs.
Artifacts such as phone books can reveal more about the society and people behind the infrastructure. Star gives an example of addition support groups being listed under “emergency services,” whereas in the past it may have been listed under “rehabilitation” or perhaps not listed at all.
This tells us something about the people the infrastructure is produced by and is intended to be for. It shows that addiction is thought of an issue that requires emergency care and not a personal failing for example, and not one that is so taboo as to be unspeakable.
Our systems can be examined similarly, whether we had a part in the design or not, we can begin to examine how points of view or assumptions have been encoded in the system. From this we can start to determine if those are intentional or useful for what we need and want.
Star extends the example to to ICD coding which is a huge system used in medicine to categorize all types of diseases, symptoms, etc… It for example includes heroin and absinthe addiction, but sniffing gasoline (at the time of the paper) was absent.
This is a useful example in two ways. It again illustrates how a system can highlight or obscure certain parts of reality. But it also shows us how difficult it can be to keep up a universal categorization system, we’re currently at ICD-10, which will be replaced by ICD-11 next year, ever expanding into new codes for different things, that may or may not be useful depending on your purpose.
Fringes and designing infrastructure
Star also taught me a new word for a useful concept, indexicality. Something that cannot be easily represented (or “put into the representation”) because it requires insider knowledge and context.
Star tells us:
To the extent that all representations are incomplete, indexicality fills in those blanks
This points us to some collisions in language, especially as we create larger and larger information systems (for example documentation libraries) that Star calls “fringes.” In one domain a word will mean one thing, but something different in another.
Star gives an example of developing infrastructure that I think most of us can relate to. She and her colleagues were investigating the Worm Community System project. Here they found further clashing meaning between the system designers and the users.
This was a pre-web system designed after studying the scientific community it was intended to serve. It also got good feedback, was said to be easy to use, and had a good understanding of the domain. Despite this many went to Gopher instead and other systems that had fewer features, and then eventually to the web of course.
Despite good user prototype feedback and participation in the system development, there were unforeseen, complex challenges to usage involving infrastructural and organizational relationships.
She explains that they had underestimated the problems that were present with local infrastructure, but also “the impact of the colliding ‘fringes between users and designers.”
They also discovered a lot of (then) unexpected things for users of the system, like feelings of shame or guilt or even lying. For example, using one system while the evaluators were looking, but switching back to another in their routine work.
This is such a relatable example for me and I think its one we can all keep in mind, that there are issues at work beyond the technical in a sociotechnical system of course. And that how people do work today, not just in an imagined future, or prototype matters a lot as well!
Star even tells us:
People are always adjusting, working around the representations to get on with their jobs and lives.
If this isn’t pointing to resilience and adaptations, people filling gaps, I don’t know what is!
Boundary objects
Another idea from Star that I think really applies to us in software systems is the idea of “boundary objects.” These are things (in her examples physical, but could be virtual) that straddle a border between disciplines or communities of practices. They serve different purposes in different contexts to different people, but because of their shared nature they allow those differing groups to work together.
She gives an example of a museum where amateur collectors and professional scientists ended up having display cases as boundary objects. The collectors liked contributing to the museum and the scientists could then label and study the objects.
There are lots of cases where our software ends up serving as boundary objects, whether by design or accident.
Takeaways
- What constitutes infrastructure can vary based on who is asking and who is answering.
- Infrastructure embeds ideas and assumptions in it, intended and otherwise, that can help or hinder its use.
- In examining systems, it may be necessary, though perhaps difficult to deconstruct the infrastructure to understand those assumptions.
- Some items of infrastructure serve to allow different communities to work together and become “boundary objects.”
Subscribe to Resilience Roundup
Subscribe to the newsletter.