What’s So Great About Reuse?

Another in my series of occasional articles espousing Enterprise Heresy… published now so that someone can read it; alas, unfinished.

Imagine this scene: the guy (and it usually is a guy, boringly enough) whose job it is to defend an IT department’s existence sitting, with his head in his hands, saying, “There’s just not enough damn reuse in these systems.”

Hmm. Assign it a probability score from 1 to 10.

Now imagine the same scene, only he’s saying. “It just takes/costs too damn long/much to deliver anything in this place.”

Is the probability score on this higher or lower than your previous answer?

Some people come away from this micro-exercise with their heads in their hands (there’s a lot of facepalming in IT). “You understand the problem!” they say, “Our leadership doesn’t understand how important reuse is! The two complaints are actually the same!”

I call shenanigans. Reuse is not a solution, it’s a technique. And in many ways it’s a darn fine one: you get to record it, track it, demonstrate ROI on it. But every minute you spending being anxious about whether or not something is reusable, you aren’t delivering something. And this approach ends up with whole teams being penny wise and pound stupid.

I’ve never seen — and don’t get me wrong, I’d love to — the Perfect Declarative Reusability Mechanism. The PDRM is simple. You feed it your requirements and a clear description of your business, and it spits out an interface and a service that will work for you for ever. But I think we’re a little way off this just yet (and if that’s not obvious to you, you’re probably not working in industry).

So we try for a solution we label “pragmatic”: an Imperfect Declarative Reusability Mechanism. We take very smart humans and put them in the driving seat. We get them to do the things smart humans are good at. Creative vagueness. Fuzzy decisions. Judgement calls. Balances of probability. Conversations over cups of tea. And we aim to get something 80% right.

The problem is that, fan as I am of pragmatism, I think that approach is harmful too, and exactly because it’s a Static World solution — it’s focused on reuse and reusability, not on dealing with the mutating morass of brand new weirdness that, for want of a better word, I call “reality”.

Before I dive off the deep end, here’s a pragmatic example: Once your service is 80% right after a month’s analysis, it’s 20% wrong. And your first consumer gets to define 100% of the 80%, or they can’t go live with it and your reputation and  line of funding look distinctly dubious. So your first reuse needs three small changes. Just three. (They’re in the 20%.) But those changes themselves have to work through the IDRM’s month-long change control phase, so they take a minimum of six weeks. And your smartest, savviest people are too busy reviewing XML schema to go and have brilliant and unsettling ideas. And it just takes too damn long. QED.

We do all this because we have a basic assumption: that change is always slow and expensive, and so we optimise to avoid it. But this is dumb, put bluntly. No one is clairvoyant, other people (in your API-exposing partners, in your competitors, in that difficult-to-think-about startup) are smart and fast, and if you think you can beat them, good luck to you. And let me know who you work for, so I can sell.