We are creatures shaped by repeated action, and our work is no exception.
Inevitably, our daily labors influence, subtly and radically, the way we see and consider the world around us. That makes sense, right? But I’m still caught by surprise when I encounter it.
Separation of Concerns 101: An Introduction
As a college student early in my pursuit of a computer science degree, I learned about a design principle that has become second nature — for me, and for most software engineers, I assume. That principle is the separation of concerns (SoC).
SoC is a relatively simple concept that has become pragmatically defined within the discipline of computing science: When creating a computer program, break the code up into manageable chunks, and organize those chunks around the different “concerns” or problems solved by the application. In typical practice (and in many textbooks), SoC looks like creating bits of self-contained code, often in separate directories and files, to handle data storage and modeling, to execute calculations and other business logic, and to define and present user interfaces.
The essayist and computing science pioneer E.W. Dijkstra (pronounced DYKE-struh, for those, like me, who just silently butchered his surname in their minds) is credited with coining the term in his 1974 essay “On the Role of Scientific Thought.”
Instructively, this simple concept — so often narrowly applied in computing science — was initially conceived by Dijkstra as a universal and necessary characteristic for all “intelligent thinking,” albeit eminently useful in computing science. In his essay, Dijkstra illustrates his timeless, freshly labeled design principle with abstract concepts, not the particularities of implementation so fastidiously emphasized by most.
With this in mind, I’ve recently endeavored to “zoom out”: to take this principle that is deeply ingrained (but narrowly applied) in the way I consider computer programming and to identify ways that it manifests, frequently unnamed, across the sundry concerns of my work at Journey Group and beyond.
SoC 201: Applied Separation of Concerns
1. Websites
One well-known and oft-published application of SoC is baked into the modern world wide web. The computer languages that comprise this very webpage are HTML, CSS, and JavaScript.
A great achievement of the early web standards movement was convincing web-workers (developers, specification-writing bodies, and browser makers) that HTML should concern itself primarily with semantics (i.e., this text is a heading, that text a button), CSS should concern itself with presentation (i.e., this heading should be bold, that button should have rounded corners), and JavaScript should concern itself with function (i.e., this heading should change when that button is clicked). These distinct building blocks (and their well-defined roles) are effectively responsible for the consistency, usability, reliability, and maintainability of the modern web.
A more recent example of SoC within the web is decoupled (or “headless”) content management. In this case, we separate the concerns of content editing and content consumption — at least, more so than they’ve historically been separated. In fact, decoupled architecture uses distinct web applications for managing content and rendering it. It’s awesome. (I’ve elucidated a few of its benefits elsewhere.)
Another way we separate concerns when planning websites is to identify audiences and goals. By taking each audience (or goal) in turn, we’re able to, as Dijkstra wrote, study it “in isolation for the sake of [its] own consistency.” Doing so allows us to discover un- or ill-considered needs, and we’re better able to determine which features and content should receive priority.
2. Web applications
Over the years, my colleagues and I have built a variety of web applications, ranging in scale from small to much less small, sometimes serving a few people, sometimes vast audiences. Our applications have tackled such disparate concerns as digital publication editing and distribution, algorithmic profile matching and content recommendations, secure file management and sharing, dynamic data visualization of large datasets, and orbital content curation. Unsurprisingly, we’ve extensively applied SoC as we’ve structured and written all the code to meet those needs.
Recently, though, I’ve noticed that even our conceptual approach to application design has embodied a more rigid separation of concerns. While it’s tempting to think great efficiency might be gained by feature-packing (meeting as many needs as possible with a single application), we’ve found that consistency and excellence are much harder to achieve as focus is fractured. Instead, our team is preferencing smaller applications that solve fewer problems. The discipline required for focusing our attention on the primary problem is more attainable when the primary problem is treated as the only problem. Without this kind of focus, efficiency comes at the cost of consistency and effectiveness.
This is not to say that we completely abandon “non-primary” problems. As Dijkstra wrote, “[separation of concerns] does not mean ignoring the other aspects, it is just doing justice to the fact that from this aspect’s point of view, the other is irrelevant.” We think secondary and tertiary problems (and the audiences affected by them) deserve to be primary — often in the context of a different, dedicated application.
On top of that, sharing data and functionality between applications gets easier every day. Applying the same technologies and techniques currently leveraged by decoupled content management, we are eagerly launching applications that make their data available to the other products we’re building and have yet to build.
3. Team design
Enough with “tech”! Let’s talk people.
Nearly a decade ago, industry trends (and our team composition) led Journey Group to experiment with a “convergent” creative practice. This meant designers with decades of experience in print were exploring how to apply their talents and learnings in a new medium: webpages and interfaces. Our web developers were likewise mixed in among print production designers, improving our production processes together by comparing similarities and differences. We learned a lot from each other, and we were able to provide immense value to our partners in a transitional period for the web (and dare I say, print).
But as the web industry and its technologies stabilized (at least, stabilized more than they’d been), we restructured our company to preference the kind of focus Dijkstra prescribes for intelligent thinking. We now group our creative practice around media: a print studio focused on designing artifacts in paper and a digital studio focused on designing experiences on the web. By daily inhabiting rooms — and hourly engaging in constructive conversations — dedicated to the unique demands of the media in which we produce creative work, we’re deepening our understanding and expanding the consistency of excellence we deliver. We still schedule weekly meetings that bring our studios together to sharpen and share, but we’ve tipped our space and time allocations in favor of focus.
As I’ve audited the ways separation of concerns has positively shaped my work at Journey Group, I’ve also discovered it improving my thinking in other spheres.
At home, my wife and I tackle many of the (endless) challenges of parenting by pulling apart the various needs expressed by a particular child in a particular scenario and giving attention to each concern in turn. At our local church (and in other civic engagements), we’re finding sanity by naming together the discrete concerns we are best suited to address and choosing to focus our limited attention and effort accordingly. Even politically, I’ve found clarity in considering policies (and politicians) by acknowledging and considering the difference between local, national, and global concerns.
Dijkstra, again:
“But nothing is gained — on the contrary! — by tackling these various aspects simultaneously. It is what I sometimes have called ‘the separation of concerns’, which, even if not perfectly possible, is yet the only available technique for effective ordering of one’s thoughts, that I know of.”
As we consider our own labors — vocational, familial, civic, and otherwise — could applying separation of concerns improve our thinking? And consequently, increase the excellence, consistency, and effectiveness of what we make?