The Good, Bad of ‘Leakage’ - Multichannel

The Good, Bad of ‘Leakage’

Publish date:

There are few times in life where leaks are a good thing. When faucets, hoses, noses, plumbing, roofs or secrets leak, for instance, it’s cause for immediate corrective action.

The same is true in software — sometimes. There’s the “memory leak,” for instance. Here’s how it manifests in everyday tech talk: “Within a week, they found something like 100 memory leaks in our browser.”

Memory leaks in software generally get pinned on bad code writing. Similar to not emptying the trash before leaving on a trip, memory leaks in software happen when the part of the code that places items in solid state memory during processing aren’t cleared out after that particular module completes what it was written to do. The result: The software equivalent of something smelling bad. Technically, those memory resources appear unavailable for the next batch of code needing them. Symptom? Software that slows down or glitches.

Recently, we happened upon evidence of leakage in software imbued with a whiff of goodness: The “intentionally leaky abstraction.” The term arose in a discussion about the Reference Design Kit (RDK) — an effort spearheaded by Comcast, and now under its own roof, with flanking support from Time Warner Cable, Liberty Global, Kabel Deutschland and other unnamed global cable providers.

RDK aims to make the “second screens” in our life accept cable video applications more easily, and to make the primary TV screen more accessible to innovation. It’s a list of open and shared-source software components (like Blink, QT, GStreamer, and HTML-5, among others) that can be used, in tight combination, to get to market more quickly with cable-specific hardware.

Let us now break down the “intentionally leaky abstraction.” Abstractions, in general, exist to occlude the underlying resource details. When you save a file to your hard drive, you hit “save.” The step-by-step minutiae of how that happens is abstracted from you (thank the heavens and stars).

The “leaky” part of the “intentionally leaky” abstraction is kind of a stretch, because nothing actually leaks. Rather, “leaky” implies that the layers of the stack (most software discussions happen in the context of stacks) aren’t sealed off . Coders have visibility “all the way down to the metal” — the silicon chip itself.

This fits, albeit awkwardly, with the definition of open that goes like this: Closed things make you wait in line: Someone (Apple, Google, etc.) must change the code and re-release it before you can proceed. Open is about being able to “see” into the stack, to do things yourself. Transparently. Self-serve. With tools that enable the drill-down.

That way, entire communities can continue coding, to refine and advance whatever the effort. It’s an “intentionally leaky abstraction” in that there are ways to see and manipulate the code in each layer.

So, may your memory never leak, and your abstractions leak in ways that help you make better products!

Stumped by gibberish? Visit Leslie Ellis at www.translation-please.comor