When is it reasonable for technology architects to go to unreasonable lengths?

Teller, the silent half of the duo of magicians, Penn and Teller, is not always silent: he’s given interviews and written articles on the theory, practice and psychology of magic.

Any insight into how people perceive and believe can be helpful to technology architects, but I think that one principle shared in this article is of particular use: make the secret a lot more trouble than the trick is worth.

The idea is that every trick has a public side (what the audience sees) and a secret side (how the effect is achieved), and that most people will assume that an apparently simple effect (the magician identifies the right card) is achieved by a similarly simple cause, and, if they cannot figure out that cause, will be mystified and entertained.

This is not just true of tricks which require apparatus and tools: even the sleight of hand, misdirection and stage presence on which many tricks rely take many, many hours of preparation and practice - much more than most of us are prepared to invest.

This principle reminded me of many of the decisions we make as technology architects: often we seem to go to a lot of trouble to achieve effects which, considered on their own, are very small - and many of our stakeholders wonder why we can't find an easier way to do things.

To understand why this is often the right thing to do, we first have to recognise that Teller’s insight is not just into human psychology, but into the economics of magic. The level of effort required to achieve a simple effect may seem out of proportion to the value of that effect: identifying a card, or escaping from a box. But that is not the true value the magician is seeking: they are seeking the delight of the audience, and the rewards that brings. And the preparation does not just pay off once: it pays off each time the trick is performed.

Now let’s take an example in which we need to get data from system A to system B. We all know many ways to do this, and we all know that some of these seem quick, easy and attractive (Dump the data to a file? Use a query tool as a bridge?).

We also know that building a proper, secure, reliable, reusable set of APIs (even if we’ve got all our tools and base infrastructure in place) will require a much greater level of effort than a simple data transfer. So why bother?

We bother because, if we have to do it many times, for many different systems, then the magic starts to work: it’s hard to believe that things are really this easy, even to the point of mystification. The unreasonable level of trouble we have gone to in creating the secret side of the trick, pays back many times over on the public side.

And we find this throughout our architectures: the level of effort that goes into creating enterprise software, Cloud platforms, open source frameworks, operating systems and all the other things on which we rely would be utterly unreasonable if we were building a single solution. But the lengths to which the creators of those capabilities have gone allows us to consume them over and over again without having to understand their inner workings.

This does not mean that we should invest an unreasonable level of effort in every solution: sometimes we just need to do something once, and we can live with a clumsy, obvious and distinctly un-magical answer. But part of the job of technology architects is to spot the occasions when it is reasonable to go unreasonable lengths and create magic.

Thinking about architectural decisions in this way is, of course, no more than looking at the familiar notion of technical debt in the mirror. Technical debt focuses on the future cost of taking the easy route today; architectural magic focuses on the future benefit of going to unreasonable lengths today. But sometimes we need to put old concepts in new clothes to see them afresh.