As developers, we build systems. Right?
We build software that stays up (in aggregate) and performs functions. Sure, sure.
Is that system useful by itself? I say never.
When your team builds a service that adds a capability to the business, and it’s called by other internal software, then that other software is essential for yours to be useful. Your service is a subsystem of the larger business software.
If your API is external-facing, those callers are part of the same larger system your service serves.
“What about a standalone app, Jess?” Take my favorite little game, Threes. It is only useful within iOS, on my iPhone, with electricity. It’s only useful because I know how to play it, and want to, and have time.
Every software is a subsystem.
Heck, even a wooden pencil is useful within a system that includes paper and people with written language. This cup is useful with running water and people with hands and thirst. My house is useful in a township with trash service and utilities and roads and property taxes. (OK Jess, stick to software.)
We don’t build systems, we build subsystems.
Jabe Bloom
When I consider the software I build as a subsystem, then I remember the larger context. I consider how it can help the other components, and how I might (unintentionally) sabotage them.
Instead of demanding requirements (“the service must respond within 200ms 90% of the time”), I can ask for performance considerations.
“This call is part of a request that needs to return in 500ms so a human doesn’t notice. This time is shared between several layers, so please don’t use more than half of it. Also, your API is called in parallel with another than takes 100ms minimum, so faster than that won’t matter.” This tells me a lot more!
Great subsystems care about the intricacies of the wider context.
Your coupon service is only useful in an economic system containing people who respond to limited-time opportunities. If you optimize for your system’s immediate revenue, you’ll increase coupon frequency. When that kills the interest of coupon users, your system is no longer useful.
Building subsystems means: it is not about you.
You are part of something. You’re not the point.
And yet!
Great subsystems also take care of themselves.
The overall business can’t function fully without your one service. The whole software industry groans when GitHub goes down. Without my threes game, how will I calm my anxiety in tiny chunks?
Every subsystem matters, so you matter.
Smoothly functioning complex systems are composed of subsystems that do their own maintenance. Our cells do a lot more than their hobs; they self-repair and even self-replace. This takes energy, and our body does not begrudge them this energy.
Our teams need breathing room to form relationships, tend to psychological health, and get the code and libraries up-to-date.
Our software tends to itself when it cleans up old files and memory (restarting in a fresh container counts). When our software emits events and surprises (aka errors), humans can find and tend to them, when it measures its own latencies, this is part of self-repair. The development team is part of the subsystem with the running software.
If the wider human system squeezes the people in our subsystem to only contribute externally visible features, then we can’t be a responsible subsystem.
If no downtime is acceptable, and blame for any incident lands on individuals, how can we keep the software healthy in continual change?
The subsystem fractures into its components: people keep to themselves. They lean on managers for career paths instead of growing themselves within teams. Now you have 50 “resources” instead of 10 teams, and getting work done is 24x harder.1
Every layer in a system has its own overhead. This is worth it for smooth functioning.
A responsible subsystem takes care of itself. The larger system’s job is to be an environment where that is easy.
Building subsystems means: You matter. And it is not about you.
This works as a personal philosopy, too.
I matter.
It’s my job to take care of myself. Only then can I continually contribute to my family, my team, and this discussion with you, the reader.
It is not about me.
If I don’t write about this topic, someone else will. (When the world is ready for an idea, it doesn’t come to just one person.)
Whatever my daughter just yelled is more about her growth and other interactions than about my feelings.
If the world is not as I would prefer it, if I find it unacceptable, it is not on me to leave or destroy it. Only to try in the few small ways I have to nudge it forward.
Building subsystems invites us to be part of something larger.
To release some ego, to take care of ourselves, to give back in all the ways we can — not by maximizing one number.
Try it. You’re already doing it — you’re already a subsystem in many systems — so try thinking about it this way. Let me know how it goes.
1 Coherence overhead seems to grow with the square of subsystems you’re coordinating (or worse). ((50 people)2 – (10 teams)2) / (10 teams)2 = 24