Software Development Is A Social Activity

I’ve had a bunch of discussions lately around the nature of software development. Silos. Boundaries. Contexts. Cognitive load. Team Topologies. And how things flow and work together. Wheels withing wheels. Loops withing loops. Patterns within patterns.

Those discussions were all around how teams can and should work together. Where does one team’s responsibility stop and another’s begin. What’s the difference between a customer and a partner? How does value flow through the system? Platforms and Programs, Products, or Feature factories. The common thread in all of these discussions is that the relationships between the teams are more important than the code. That software development is a social endeavor.

Despite the myth of the lone wolf developer, for all but the tiniest projects/products on all but the tiniest embedded devices, you can’t do it alone. We build things with others. We build things for others. We don’t do our work, and our work does not exist in a vacuum.

On the other hand, no-one can know the details of everything. No one person can have enough information to make all the decisions needed. The cognitive load of that would be too high. No one can be in the right place to make all those decisions. Physics and time keep us from being in multiple places at the same time. So where does that leave us?

It leaves us with process and methodology. We come up with boundaries. Domain driven design. Bounded contexts. Discrete APIs. We come up with contracts and SLAs. Things that let us share knowledge and compartmentalize responsibility. Things that let us manage the complexity. Keep the cognitive load manageable. That let us focus on the things close to us and not worry about the things further away.

Or at least we aspire to have those things. But, honestly, we don’t. Instead, we have approximations. Leaky approximations. We have APIs and interfaces and microservices, which mostly let us not worry about the details. Except for the ones we do need to know.

Which means we’re back to people. And how they interact. People who need to talk to each other. Need to work with each other. And talk across all those leaky barriers. So they can make decisions across those leaky barriers. And use the fact that the barriers are leaky to help each other across those leaky barriers. And at the same time make the barriers less leaky.

As I write this I’m sitting on an airplane watching The Matrix: Resurrections. Talk about leaky barriers. There are the (semi) obvious barriers between the Matrix and the “real” world. There are the barriers between the world inside the (semi-real) Matrix and the Matrix computer game which Thomas Anderson has written. There’s the barrier between incarnations of the (semi) real Matrix. And that’s all inside the universe the movie takes place in

On top of that there are the barriers between the different Matrix movies. And The Animatrix series. And the changes the writers/directors have gone through. It’s almost like the directors and characters in the movie know that there’s an audience watching.

The leakiest barrier of them all is the audience. The audience knows many things about the in-movie universe that the people in the universe don’t. But there’s no guarantee that they’re not actually in a (the?) Matrix. After all, how would you know? Which is about as meta as it gets.

The thing is, what makes the caper in The Matrix work is the same thing that makes software work. The connections between groups. Within and across the leaky barriers. The understanding. The shared goals. The trust.

Because in the end, software development is a social activity. The choice is yours.