Unencapsulate Yourself

We loved to escape the boxes when we were kids… Photo credit: thewoodenshoes (Flickr)

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 Continue reading


I signed two software manifestos yesterday.

photo credit: SpecialKRB (Flickr)

The Agile Manifesto is a classic. It changed the industry. Not everything about “agile” is automatically wonderful (particularly when it becomes an excuse for lazy planning), but the foundational principles are so, so true! Go. Read. Sign.

The Manifesto for Software Craftsmanship seems to deliberately emulate its predecessor’s simple and pragmatic style. I also believe deeply in its principles. I think it needs a bit more defense, however.

Steve Yegge claims that software conservatives love their code, and software liberals view code as a necessary evil. (LONG post; this comment is near the end. And you may need to read his previous post for context, if you’re not familiar with his political metaphor.)

I think he’s gone too far. I’m pretty software liberal. And I get the kernel of truth in the “necessary evil” idea. So much of what we write will be chucked or rewritten; it’s unhealthy to imagine that every project is an opportunity for a magnum opus, or to expect to be able to achieve perfection.

But I don’t think that means we should devalue the craft. Even in the imperfect, muddled, transitory universe of software, it’s possible to make savvy and artistic choices–or to do the opposite. When we care about craft, we find work more satisfying, and we make our corner of the universe a more hospitable place for our neighbors, which has all kinds of benefits.

Besides, love of craft is my major reason for blogging, so it must be a good thing, right? :-)

Action Item

Go read the manifestos. If you’re inclined, poke around for the links that let you sign.

Evolving Software Politics

I find a lot of insight in Steve Yegge’s suggestion that we think about the world views of software engineers along a conservative (risk-averse) versus liberal (change-friendly) axis. I have some quibbles, to be sure:

  • I’m not sure how well Steve’s labels resonate outside the U.S.
  • I think software conservatism is more focused on permanence than risk aversion.
  • I don’t think programmers are all that consistent in their views. I can find evidence of both soft-con and soft-lib thinking in my own philosophies.

That said, I think I’ve evolved from a conservative to a more liberal perspective over the years. At one point in my career I got quite annoyed at C++ coders who were careless about how they used const. It still bothers me a bit–but now I care about productivity more, and I buy the value of languages enforcing best practices less, than I used to. I love python and “convention over configuration“–both liberal favorites. My idea that teams should deploy evolving software by assigning humans to role play architectural components, and see what happens–that’s about as ultra liberal as it gets.


Why has my world view evolved?

I think I’ve come to agree very strongly with Steve’s observation that software is impermanent. Little if any software stands the test of time. In the mid ’90s I worked on some Visual Basic code that had ancient Basic modules in it, with comments from the mid 70’s. I hated that code–imagine the worst features of spaghetti code, hungarian notation with obsolete data types, deep technical debt, tight coupling, poor encapsulation…–this was a poster child. The code wasn’t dead, but it should have been. 20 years is too long for almost all code. (I’m adding a chapter about the profound benefits of death in my biology~software metaphor, in my forthcoming book, Lifeware.)

When you accept that software is impermanent, you can relax. There doesn’t have to be a centrally planned vision that remains constant over time; you can discover things as you go, and it’s all right.

Don’t confuse this with me being lazy. I think code should be clean and cohesive; see my posts on “good code” for more on that. I’m simply saying that you should embrace the idea that things change. Requirements shift. Teams go through learning curves. Staff has turnover. Products lose or gain competitive advantage. The market adjusts. Better frameworks come out. New OS features appear. And the implication of this change is that today’s right answer might need some tweaking tomorrow.

Faced with that change, the ability to react quickly and calmly, to be entrepreneurial and experiment-driven, is often of greater business value than a perfect piece of code.

Action Item

List three things about your project’s landscape (market, team, technology, …) that have changed in the past year. Do any of these make earlier decisions more or less appropriate?