deployment

Encapsulation isn’t just for code

When computer science folks talk about encapsulation, they are usually thinking of how the principle applies to objects and functions inside a codebase. Best practice calls for a separation of concerns–each object responsible for one type of work, hiding all details from its neighbors.

That’s great. But it’s not the only way encapsulation ought to show up in software.

In actual deployment, software packages often manifest anti-patterns in the way that they are configured. A web server has to know all about three different database servers that contribute data for its pages; HA failover scripts must know the identity and responsibility of every actor in the system, as well as many particulars about how these entities use resources to accomplish their tasks.

No wonder our deployments are fragile and high-maintenance…

The cloud computing wave is raising the bar for encapsulation in the way applications–not just objects–discover and interact with one another. In this week’s installment of my series of posts about how to “cloudify”, I discuss how role-based interactions insulate components from details they don’t need to know. It’s encapsulation all over again. And this encapsulation pattern manifests itself in unlikely places–like the order queue at McDonald’s…

What can McDonalds teach a developer of cloud-friendly software? photo credit: phogel (Flickr)

Stay tuned for further installments of this series each Friday. As I said in Part 1, I believe that a competence with cloud–cloud-oriented programming, if you will–will be a checkbox on future tech resumes.

Flexibility is No Virtue

Vice is a monster of so frightful mien,
As to be hated needs but to be seen;
Yet seen too oft, familiar with her face,
We first endure, then pity, then embrace.

—Alexander Pope, Essay on Man

If I had a penny for every programmer that I’ve heard, proudly touting the flexibility of what they’ve built, I’d be a wealthy man. I might even be able to afford my teenagers’ car insurance. :-)

As a young coder, I took the implied excellence of flexibility for granted; after all, who wouldn’t want to be flexible?

Now I know better.

If your software can be installed and configured a hundred different ways, this is Not Good. It is a sign that you don’t know who your customer is, or what they want. If your programming language has nine separate functions that provide the same functionality, shame on its designers. If your UI presents users with oodles of choices and calls it a customer focus, go vomit into the nearest garbage can.

V22-Osprey — an unusually flexible aircraft. Photo credit: Sgt. Mike Fayloga (Wikimedia Commons)

I can already hear the protests, so let me pause here to admit Continue reading →