The last several days have yielded a surprising validation for some design choices we made for developing PluralBridge. The biggest challenge we struggle with is how to create an application that allows Systems to be modelled as a user’s lived experience, without falling into the deadly trap of overdesign, or worse, creeping featurism. With that background, let us regale you a tale of a happy accident in a design choice. In the beginning....
...when a developer is indoctrinated into developing software for clients, they tend to learn some hard lessons as they progress through their career. First and foremost is, make sure to get the design, use case, and growth projections. By no means does this mean you will walk away with everything you need. What you do get is a baseline, and as you accumulate experience, you learn to anticipate where to leave wiggle room on numbers, and where to drill down for the detail required to get a solid foundation that can withstand change without tearing out the support beams and starting over.
Early on in our career (very early on) we were asked to develop a “simple” inventory and cash management application for a small boutique store. The target hardware platform was a TRS-80 Model III with 48K RAM - that’s usable RAM, the rest went to DOS and BASIC ROM(s). To put that in perspective in today’s world where users typically traffic in gigabytes or even terabytes, the task was tantamount to fitting the entire Declaration of Independence onto a postage stamp.
Acquiring a customer can be a euphoric experience, especially when you are first starting out. We did our “due diligence” - according to the client there was a customer flow of about a couple dozen a day, and ~100 items in inventory. We had acquired enough development experience to know that our “database” on floppy would have to use a token as a unique ID. We reasoned to ourselves, ~100 items, even if it doubled, should fit nice and snug inside of a byte. Keep in mind, every byte mattered both in memory and on disk.
Not long after we got a frantic call. The Receivables, Payables and Inventory reports were just wrong! Items and their attributes were getting cross matched, and the reports were basically useless. It didn’t take long to ask the question we should have verified; exactly how many unique inventory items did the client input? Answer, over 400! yeah, not hard to see where a byte which can hold up to 255 unique items (we reserved ‘0’ for our app logic) would overflow on item #256. That wasn’t the worst of it - in 48K of RAM we could hold the inventory IDs in memory to speed up access. An array of 255 elements might not sound like much, but RAM was a precious resource - doubling it meant our program would no longer fit in memory.
In the end, we punted; we doubled the size as needed expanding the number of unique items to 65535, and rewrote chunks of the BASIC code in assembler. As a by-product, it actually sped up the program considerably. The cost? A week of sleepless nights and feeling very stupid for having not anticipated this. House said it best, “everybody lies”.
That leads to the second cardinal rule: When designing software for a client, reduce the number of choices to as few as possible to minimize surprise. For many problems developers face, that largely works. However, all choices have consequences, and when you limit the palette from which your client has to choose features, you can miss the bigger picture. Worse, you may be working under the pretext that you can confidently design something for users without ever cross checking if what you are building will serve the largest number of users while maintaining a sound foundation.
This is that tale...
Happy accidents are unintended events or apparent mistakes that produce unexpectedly useful (and often better) results than what the creator intended or expected. Modern music is littered with riffs or lyrics that became legendary, so much so that they enter the mainstream as if they were always meant to occupy that space. Engineers run into similar unanticipated results trying to solve an entirely different problem than what their discovery yielded.
Some notable examples yielding discoveries that anyone in this time cannot imagine living without:
In 1945, Raytheon engineer Percy Spencer was working near an active magnetron when he noticed that a chocolate bar in his pocket had melted, leading him to suspect that the microwave radiation was heating the food. He experimented with other foods, including popcorn and an egg, and the discovery ultimately led Raytheon to develop the first commercial microwave ovens.
In 1968, 3M scientist Spencer Silver was trying to develop a strong adhesive when he instead created an unusually weak, pressure-sensitive adhesive that could stick to surfaces and be removed repeatedly without leaving much residue. Years later, colleague Art Fry wanted bookmarks that would stay put in his church hymnal without damaging the pages, remembered Silver’s odd adhesive, and the combination eventually became the Post-it Note.
Our colleague Sharky Yellowfish cast a net yesterday after an intense session with their therapist asking a seemingly innocent question: “When you look into the mirror, who do you see?”. They were wrestling with how their System inhabitants ranging from age 4 to 40 literally see themselves and how others see them, depending on who is fronting.
That yielded a rich and frankly unexpected range of replies from real Systems and their lived experience. It also exposed a design flaw in our implementation of both how a headmate identifies, and how they express their pronouns.
Here is where our happy accident begins.
Up until now, we had been thinking about identity in much the same way most software designs do: give someone a field on a form to select an adjective that best describes how they identify. Provide them another field on a form for their pronouns. Perfectly reasonable, right up until real people start answering a question thrown out into the ether - when you look into the mirror, who do you see?
Contrary to the reply shape we constructed in our own head(s), user comments did not arrive in neat little buckets. One headmate might identify as a woman, a trans woman, plural and lesbian, with each of those words carrying useful information. Another might have an entirely different relationship with gender. Some Systems described headmates whose gender differed from the body, others whose age changed how they perceived the body, and still others described members who were animals, creatures, fictives or otherwise not human at all.
In what can only be described as a “D’oh” moment, our entire concept of “Identity” no longer inhabited the limited cage we gave it.
Our first instinct might have been to add more adjectives. Gender. Sexuality. Species. Fictive status. Perhaps a few more checkboxes for things we had not thought of yet. No, that won’t work. Maybe add a custom fields box to add more adjectives for Systems that don’t conform to our own limited lived experience. That road has a very familiar destination: every time somebody teaches us something new to describe themselves, we are forced to make a change. Maybe it’s software, maybe a database join table. This has a very distinctive code smell. Can’t ignore the battle scars of our creations we leave behind.
What if, instead of seeing identity as a ‘one size fits most’, we instead see it for how human beings actually move socially? If we were to describe ourselves, our composite might look like:
Identity: Trans woman, engineer, musician, mother, progressive, DID, curious, risk taker, tired.
A composite of otherwise potentially orthogonal adjectives that individually provide only a small glimpse into who we are. The whole is greater than the sum of the parts.
Sometimes the gods that provided the circumstances of a happy accident might also provide affirmation. We were already moving this idea around in multiple dimensions when we encountered the first response that said simply ‘wolf’. And just like that, we saw how our model could seamlessly provide the necessary parts to this new approach:
Identity: Animal, wolf.
Then we got to thinking, what if we could intuitively provide ranking based on which adjectives came first? Make a mistake, deselect choices until you reach the last known good point, and select new tokens in the order you perceive.
And what if we could make it intuitive and easy to add new choices? What if we then displayed this?
Identity: Animal, wolf, [+]
Like the defaults? Leave it as-is. Want to edit/add the identity tokens? Click the ‘+’ sign.
Sharky went looking for an answer to what plural people see when they look into a mirror. Instead, dozens of people describing their lived experience handed us a better abstraction for identity and pronouns.
That is what composability buys you. The pieces can remain small while their combinations describe something much richer, and the next person does not have to fit themselves into whatever collection of boxes we happened to think of first.
Sometimes a melted chocolate bar gives you a microwave oven. Sometimes a failed adhesive gives you a Post-it Note.
And sometimes you ask Reddit about mirrors and accidentally redesign Identity.
