When Branches Break: the Separation of Concerns
We do it in democracy, computing, warfare, commerce, academia, networking, and even art: the separation of concerns (SoC). To separate concerns is to allocate responsibility not by workload or capacity, but by control flow, intent, and function.
Like sex, morality, or the law, most of us hold this idea in legendary standing without even realizing it (if usually not all at once). In government, we call it Separation of Powers, or trias politica. In software, where the term originated, we turn to Object-Orriented Programming (OOP) and Model-View-Controller (MVC). In military and intelligence, Command & Control (C2). In business, organizational structure. In education, special scholastic disciplinarity (SSD). In telecoms, mesh network topology (MNT). In filmmaking, crewform. The list goes on and on, because SoC is everywhere.
SoC’s goals vary by circumstance, but can generally be classified into five pairs of principles: modularity and agility, extensibility and abstraction, encapsulation and deconnascence, layering and specificity, and understandability and scalability. For those unfamiliar with these principles, the specifics aren’t important (though I encourage you to investigate them)… The point is, SoC is clearly a valuable, popular, viable construct.
These goals contribute to a deep efficiency at each and every stage of the process. As mentioned earlier, SoC tends to shun “workload” and “capacity” as organizing principles, in favor of control flow (how chains of actions mesh), intent (purpose), and, function (what underlies responsibility, and how it’s carried out). The result is a set of efficiencies scaled by the goals just mentioned: efficiency scaled by agility, efficiency scaled by understandability, etc. Their sum efficiency is much more useful and diverse than an efficiency based on workload. But to quote the great Eberhardt Rechtin, former Director of DARPA:
Are not all great system designs, in their essence, about efficiency?
Imagine developing an app with limited time. Imagine setting up a home theatre so simple your granny could use it. Imagine running a corporation with thousands of workers. Imagine invading a foreign country across globe… Isn’t the magna quaestio always one of efficiency?
Some would call this an argument for hierarchy. After all, the ladder is a simple, effective machine. Stereotyped though it may be, Marvin Bower, the visionary behind McKinsey & Company, famously said of hierarchy, “The thing is, it works.”
Some manifestations, though, categorically malfunction — corporate bureaucracies, blocking single-threaded programs, etc. Hierarchies have a tendency to get mucked up by sludge. Hierarchies have a tendency to be inflexible. Most importantly, hierarchies are not trees. Metaphorically and representationally, the two are very|often|confused, but hierarchies are actually finely-balanced inverted pyramids. In that light, I ask you: Have you ever removed the capstone or keystone from an inverted arch or pyramid? Seeing as we’re short on inverted pyramids in real life, I doubt it, but you can imagine the disaster that would ensue.
If you’ve ever cut a branch, you know the answer: the tree remained, intact. You could’ve cut the branch, painted it blue, bent in backwards and fixed it back on… the tree would’ve been as it was.
Back to the Separation of Concerns. No matter what the circumstances or concerns, there exists and persists a constant separation of strategy and tactic. It’s about decoupling the domain logic and service logic: heck, cut a branch in MVC and you get an n-tier structure… nearly the same thing, and just as useful. As a “process architecture”, “organizing principle”, “design pattern” or whatever you want to call it, this makes SoC extremely valuable. The thing is, it contradicts intuition and human nature. SoC takes great effort to implement, because even as it’s logical, it’s very artificial. Humans don’t tend to separate their concerns; they like to, but don’t tend to. As individuals, we don’t usually allocate moments for emotion and reason, or, for that matter, thought and action. When writing our first computer program, or launching our first startup, our proclivities are more monarchial, more single-threaded than distributed — certainly not “separated in concerns”.
So yes, SoC takes work to implement. But if nothing else, it’s because SoC is a projection of the ideal framework — the ideal self — all systems designers aspire to. It’s the ultimate machine: where the logic goes (control flow), what it means (intent), and what it does (function). It perpetuates the overall scheme, but permits each piece only enough concern for itself. It’s efficient, high-level, responsive, and does well across a variety of scenarios.
If I could be more like SoC, I would. You too? Not surprised.
But we’re human.
Suppose we’ll have to settle with MVC for now. ₪