Design principles are constantly drilled into the brains of software developers. From concepts like the SOLID principles, to design patterns, and broad architectural patterns such as microservices, it seems like it never ends.

Now maybe it’s just me, but when I learn about one of these patterns, I try to extrapolate the larger truth it’s attempting to convey, and naturally, the context to which it does (and does not) apply.

Let’s me demonstrate with the Single-responsibility principle, the S in SOLID.

This is typically described/defined as:

A module should be responsible to one, and only one, actor (a group of one or more users/stakeholders).

This one (and more broadly, all of the SOLID principles), are frequently criticized as being too focused on object-oriented programming principles which not everyone uses. And maybe as it’s worded, that can be technically true.

But doesn’t this concept (responsibility to a single person/group) apply in many other areas? Even non-coding areas?

I mean, does it make sense for an employee to have responsibility to 8 bosses?

Or how about the goal of microservices which is (other than résumé building) often touted as decoupling of dependencies. Does this apply to non-services? I think it does. That’s also the goal of Scrum’s cross-functional teams.

I’ve been surprised at times when others don’t see these parallels. But like I said, maybe it’s just me.

Well, it’s not just me. Melvin Conway, of Conway’s law fame noticed as far back as 1967 that software system structure seems to follow organizational structure. But I think the similarities deserves a lot more attention and exploration.

What other parallels do you see between software design principles, and team/organizational principles?