If I had to make a “top 5” list of foundational tools in software development, encapsulation would certainly make the cut. It’s a major enabler of abstraction; it’s what makes conceptual complexity tractable.
Recognizing its importance, most modern programming languages encourage encapsulation in one way or another. For example, languages friendly to OOP lead coders to think about the world in terms of well encapsulated objects and the messages they pass.
I’m a big fan of encapsulation.
But if you never leave your boxes, you miss half the fun.
Layers and silos
As cells grow into tissues in biology, so similar objects in an OOP mindset often coalesce into horizontal layers composed of entities with compatible composition and duties. These strata get names: “the business logic layer”, “the display layer”, “middleware”, “core engine”, and so forth. If you’ve worked on anything MVC or n-tier or client-server, you know this mindset.
Less commonly, objects align on a vertical axis, producing semi-independent silos that span layers to produce decoupled top-level features. An optional accounting module that has its own db and middleware might be modeled as an independent stack in a vertical architecture. Aspect-oriented programming also spans layers, though in a less siloed way.
In either case, the boxes you draw to model your architecture tend to correspond to teams, and those teams tend to use different tools and processes, and those differences tend to isolate rather than converge organizations.
This is a problem.
You should encapsulate code. People, not so much.
Generalists and specialists
Specialists have their place. But if your dev organization is overly skewed toward specialists in each architectural box, it is not healthy. To understand why, join me in a thought experiment.
Bob is sick. He’d like to get some help. But he happens to live in a society where the health care system consists entirely of otolaryngologists and endocrinologists and neurosurgeons. He has no general practitioners to listen while he paints a picture with broad brush strokes–nobody who will triage and cut to the chase.
You can imagine what happens next. Bob visits one specialist, but the specialist sees Bob’s problem as only intersecting 20% with her particular expertise. Wanting to be sure she’s not sued for malpractice, she recommends that he consult with another specialist as well. Bob makes another visit, and gets another referral. After half a dozen trips, he’s now explored 100% of his symptoms, and he has a set of diagnoses and prescriptions that theoretically address his problem. However, nobody has examined the picture in the aggregate, looking for redundancy or incompatibility. Instead, nurses have been on the phone to other offices, and faxes and charts have passed back and forth like ping-pong balls, with uncertain results. Bob has spent so much money and accumulated so many complex recommendations for a cure that he’s a bit bewildered. And it’s taken a large amount of time.
Organizations that encapsulate people into layers or silos map nicely onto this thought experiment. If you want to build a new feature, or fix a bug, you ping-pong around to various specialists, trying to get a straight answer. Communication by document is the norm; people blame poor internal docs for design oversights. Estimates are high, mainly due to concern about touch points between layers. Use cases are written in terms of a horizontal layer; nobody seems to remember that the top of the stack is the entire universe as far as the user is concerned. Specialists don’t trust one another’s diagnoses. Fiefdoms proliferate; ambassadors may negotiate treaties, but political tensions are high. When time comes to actually implement the feature or the fix, you see an inordinate amount of baton-passing, cross-checking, critical-path’ing, and hand-wringing. These orgs struggle with integration (usually vertical) testing, since it doesn’t map well onto the scope of concerns of any incorporated entity; even in the best of cases, they have a hard time identifying the highest-value test cases, since team walls limit insight into risk.
Give me a proactive, first-class generalist in a silo’ed or layered org, and I will give you a high-leverage change-maker that’s a linchpin for company success. They will be invited to every meeting (although they won’t succumb to death by meeting, if they’re smart.) They’ll cut through ambivalence, see the big picture, and make smart tradeoffs. They’ll lubricate the cogs of the machine in a way that an equally smart, but siloed, technical pro cannot.
I’m not saying that everybody should be a consummate generalist; the pendulum can swing too far. Medicine needs pediatric allergists, and software needs the cube warrior who can make gdb sing on AIX on an RS-6000 like nobody else on the planet. But it’s telling that you can’t specialize in medicine until after you’ve satisfied general requirements for a medical degree.
If your software teams are overly siloed, consider instituting some cross-training. Start measuring how often a single person can solve a bug all the way up and down the stack. Incent your best engineers to learn to speak another team’s language; maybe loan a few to another scrum team from time to time.
If you’re an engineer, unencapsulate yourself.
Thinking outside the box pays big dividends.
Identify one way that you can learn something about the problem domain of a team other than your own. Pay the price for that learning. Then put your investment to good use.
- Encapsulation Breaking (dailyjs.com)
- Touching the stove, broken glass, and other people’s mistakes (philcrissman.com)
- Breaking Up with IoC Containers (architects.dzone.com)