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

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

Book Review: Poke the Box

I just finished reading Seth Godin’s Poke the Box, and I recommend that you add it to your reading list. It’s short, punchy, and thought-provoking.

 

The main idea he advocates is that we should not wait around for the world to give us permission, and we should not be afraid to fail. We should just jump in with two feet and make things happen.

My favorite phrase from the whole book–and a great three-word summary–is “Now beats soon.” Kind of reminds me of the favorite motto of a wise leader that I admire: “We must lengthen our stride. And we must do it now.” (Spencer W. Kimball; he had “Do it now!” on a plaque on his desk.)

Yes, there are a few caveats. Some people are forever starting, but never finishing. That can be a problem. And you have to do your homework before you start; you don’t want to jump in until you know whether you’ve picked a smart place to swim across the river.

The only critique I have is that Godin could have said the same thing in about half the space. He has lots of short anecdotes, which are fun, but he had me convinced long before I got to the end.

Action Item

Go out and do something great! Now.

Paying Off Technical Debt

We don’t get spam about how to consolidate our technical debts. :-) Image credit: Alan Cleaver (Flickr)

“Interest never sleeps nor sickens nor dies; it never goes to the hospital; it works on Sundays and holidays; it never takes a vacation; it never visits nor travels; it takes no pleasure; it is never laid off work nor discharged from employment; it never works on reduced hours. . . . Once in debt, interest is your companion every minute of the day and night; you cannot shun it or slip away from it; you cannot dismiss it; it yields neither to entreaties, demands, or orders; and whenever you get in its way or cross its course or fail to meet its demands, it crushes you.”

J. Reuben Clark

In my recent post about how organizations forget technical debt, I glossed over some important details. When you’re in debt, you have an obligation to pay somebody back. So: with technical debt, who must you pay, and how?

More than just a code problem

A simplistic view–one that I’ve used for years–understands debt mainly as a deficiency in code. In this view, you pay yourself back by making the code better. Most discussions about technical debt take this view. It’s natural, and true, and useful.

However, I don’t think it’s the full story.

It’s good practice to borrow money from yourself. If you do things this way, you save a bunch of capital, and then you borrow against your own reserves. Paying yourself back consists of transferring money back into your own savings.

This is hard, and making large purchases this way requires years of prior planning and discipline.

A more common way to borrow is Continue reading

Coping With Organizational Alzheimers

Years ago, an astute manager summed up a problem that I had only vaguely intuited up to that point in my career.

Do our memories leak? Image credit: xpectro (Flickr)

“A big problem with most companies,” said Roland, “is that they have no institutional memory.”

As I recall, Roland was describing capricious political winds, and lamenting that the only form of loyalty a company has to employees is the kind they put in writing. As soon as there’s major M&A activity, or HR decides to rebalance salary allocations, or an incentive program gets adjusted to the latest management fad, all recollection of old priorities and soft obligations vanishes in a puff of smoke.

If anything, Roland was understating the problem. Companies routinely panic and change strategy half-way through an investment cycle, because they can no longer articulate the rational analysis that led them to take a plunge. Buzz floods the internet about some innovation that makes everybody excited, but we forget that we’ve heard the idea before, behind some different terminology. (Are you nodding your head because “cloud” in the last few years is just a recycling of “utility computing”from circa 2000? Trev, a colleague of mine at Adaptive Computing, showed me a dog-eared copy of The Challenge of the Computer Utility, by Douglas Parkhill. It’s all there–XaaS, elastic and on-demand, in 1966. And who knows–maybe sci-fi writers or the designers of Eniac had thought of it even before Parkhill…)

But I digress.

One particularly insidious form of forgetfulness in software relates to technical debt. Another colleague, Doug, reacted to an expedient workaround this way:

My one regret with this is that by doing something that is good enough it will never get the attention it might deserve to be made better. This happens each release: we make compromises at the very end to get it out the door, promising ourselves that we’ll revisit it later.

Folks, we don’t keep these promises to ourselves very well; Alzheimers is endemic with regards to technical debt. The only thing that saves us is that Continue reading