Reuse: a Recipe for Disaster
Think thrice before using twice
Technology reuse is too easy to say and too hard to do well. Look before you leap: pride comes before a fail.
If you’ve been through the process of selling the case for a technology project to agree funding, you’re likely to have come across the mantra of “reuse”. It’s a powerful and tantalising idea: invest in building something strategic and make it generic. Do it in one place and the rest of the organisation will benefit. Whether a capability or a product, if it can be repurposed to meet the needs of other areas, it’s a win for “invest once, benefit many”.
But no plan survives contact with the enemy. Putting theory into practice is hard. It turns out reality is nuanced. Who knew? Authoritative, yet simplistic assertions about reuse routinely bypass past experience of just how much work it takes to make something reusable.
I’ve been through the mill enough times. I’ve worked with teams that struggled willingly, trying to support the aspirations of their leaders. I’ve seen time, energy and goodwill burnt from every angle and trust and relationships ultimately fail. If results were delivered, they were too little, too late, too brittle, too hard to support and dangerous to change.
Technology moved and the system couldn’t be moved. Legacy by defacto design.
Reuse comes in a range of flavours. We’ll look at two of them. I hope to equip you with just enough doubt about this orthodoxy to prompt a new way of looking at the world. We’ll go on to explore some language to express what good could look like. This is going to get dark for a little while, but there will be a dawn. My hope is the journey will be cathartic.
Scenario 1: the enterprise software myth
Enterprise software is dangerous. It crushes projects, organisations and careers. I’ve been on every side of these fences and I have scars. The irony is, the more it costs, the worse it gets. Sales are targeted at C-level execs and non-technical senior management because tech teams won’t touch it. Sometimes the software plain doesn’t work, often it hasn’t been written yet and when it does turn up it’s held together with sellotape and string.
It’s a feat of white-collar social engineering and it bleeds the budgets of our governments and most cherished institutions dry.
Here’s an enterprise software pattern I’ve seen repeated with alarming regularity: let’s build an organisation-wide deployment and hosting platform. It’s a good idea. In theory. Provide a standard deployment system that every technology project across your organisation can use. This means less effort needs to be invested by each project to deliver working software. Standardisation is good and the whole organisation will benefit. Case made.
Here’s the fly in the ointment: I’ve never seen it work. Project teams find themselves months and years down the line, struggling to realise meaningful value. The reality is the payoff is negligible compared to the cost, not just in money but in time — how far behind the curve you can drift whilst trying. Here’s someone independent talking about how Kubernetes (k8s) turned out:
The reality of operating complex, generic, reusable infrastructure — and doing it to production standards — will keep the promised land of milk, honey and standardisation just over the rainbow, always two weeks away, beyond the next invoice, jam tomorrow.
There are entire businesses, like Heroku, dedicated to this stuff. The global-scale operations of Amazon and Google spend hundreds and thousands of engineer hours on the art of just building and operating a platform. The UK Government Digital Service has been working on a Cloudfoundry Platform-as-a-Service, at national scale, for years. It’s taken so long that the chances are it’ll be eclipsed by commodity cloud provider services. To be clear I don’t have an inside track. It just seems obvious.
Technology commoditisation moves faster than enterprise software can be implemented
This should break glass and set off your mental fire alarm. The sheer scale of this capability means it must be externalised. The effort needed to do it well dwarfs what your organisation is ultimately trying to use it for. It’s like bringing an aircraft carrier to a boating lake.
An initiative genuinely intended to improve things becomes a sparkling white elephant. And then the money is gone.
Still with me? Let’s visit one more heart of darkness and then climb to a more hopeful place.
Scenario 2: the apples and oranges myth
There’s another kind of reuse. It believes in “build it once and everyone can use it”. The narrative is that investing in building something in a generic way will be cheaper — and smarter. The origin of this belief is compelling. Absent technical intuition, it looks eminently sensible. It goes something like this:
Our organisation is in the fruit business. We are starting a project to sell Apples. This will require significant investment. However, we already produce Oranges, fairly successfully, but this needs modernising. Since these are both fruits, we’ll develop Apples in such a way as to make it reusable for producing Oranges as well. We envisage, over the next decade, that we’ll be able to further use apples to produce Raspberries, Bananas and potentially go as far as Potatoes.
Once this idea takes root and starts to grow, it’s extremely difficult to halt the spread. A project team may point out that, “you know, Apples and Oranges”. A team willing to take risks to avoid their leaders ending up with egg on their faces may point to the fact that a potato is in fact a tuber and that a banana plant is technically a large herb. You can probably feel that, where these messages fall on deaf ears, seeds of trust breakdown start to take root.
Ultimately it’s a Shangri-La. There is in no mystical and harmonious place where one piece of software can effortlessly serve different functions. Why is this?
Software is near-pure design. Design is about intention and where intention varies, so must design.
One purpose, one design. The simple fact is it’s extremely difficult to design something that serves even two purposes. Even where there’s low uncertainty about what those two purposes are. With efficient modern languages and agile thinking, it’s typically cheaper to build many things — one for each purpose — than to build one multipurpose thing with lots of moving parts.
This kind of reuse ends up fitting what invariably ends up being a somewhat square peg into an ultimately rather round hole. It’s a never-ending source of pain, friction, cost and failure in technology projects.
Good reuse
I’ll go out on a limb here. There’s such a thing as good reuse. If you intuitively know this then you’ve probably been thinking “yes, but..” as you’ve been reading.
And here it is: single-function capabilities, with clear purpose and solid boundaries. Well designed things that know what they do — and don’t do. Low-uncertainty, commodity components. Whether it’s software libraries, cloud infrastructure or office productivity software, if it works to well-understood, public open (defined or defacto) standards that have nothing to do with the specifics of what your organisation does then reuse is your friend.
Bad reuse
Anything that’s in the “personal space” of your organisation’s mission takes you into the danger zone. Think long and hard before using generic technology to define the specifics of your business or user experience.
Why? Because your business is then defined by someone else’s technology roadmap. The intentions of their organisation by definition don’t fully align with yours. They must serve many masters.
Fixing: enterprise software
Avoiding failures from enterprise software is always going to be tricky. Let’s assume you’ve got the right product, that your technical team is satisfied that it’s of sufficient quality and that you genuinely have the need it’s intended to address. We’ll add infinite budget, time and team to round off the list.
To design a good solution, we have to engage with dirty, practical reality
That’s never an attractive or easy prospect. Whether it’s senior teams making plans in glass boxes, technical architects drawing perfect diagrams in ivory towers, or developers with fixed thinking about the one technology that is the answer to every question, it’s tempting to avoid genuine engagement.
Ultimately that engagement is the only route to real success. It feels vulnerable and it might mean changing your ideas, but in the final analysis that’s a much better and more productive cost next to the alternative.
Fixing: apples and oranges
Apples and oranges may seem a simpler fix compared to the idealised list of prerequisites for enterprise software, but it may require a fundamental shift in what feels right. That’s not an easy ask and may require personal change on a deeper level. I’ve been impressed with the “rule of three” as a guiding principle. Whilst this won’t necessarily effect the deeper change, it can provide a rational framework.
The idea is simple: if you’re building something for the first time, focus only on what you’re building. No potential future requirements, no multi-purposing, just a straightforward, specific, unglamorous solution. This will be cheap and will have a decent chance of delivering value.
It may not look strategic, but the strategy is deeper here.
If and when you really do build something similar, do exactly the same thing. What? Yes. Be specific, be direct, keep it simple. Again you’ll deliver value and it’ll be a lot quicker. You may also avoid Second System Syndrome.
If and only if you find yourself building the same thing for a third time, will you likely have enough data, experience and discernment of the subtle differences and practicalities to see whether (or not) apples and oranges really belong in the same basket.
Even if they don’t, you’ll have been able to deliver before technology moved on. That’s a big deal in itself, compared to many projects. What you’ll learn from evolving technology may even help you update the previous systems, preventing them “decomposing” and becoming legacy. Technology rots pretty quickly these days.
The deeper answer
The lofty ideals of reuse become vague, difficult and expensive in a world where the dynamics favour quick, tailored and delivered. The truth is we all form beliefs about how to get by in life and what is good and bad — what works and what doesn’t.
One of the great human skills is to be able to perceive that we have these beliefs and, when they start to create friction, wonder if they need to be updated or dropped. The world changes and if we can change gracefully with it, life flows more smoothly.
Reuse is one of these beliefs. We need to update that. In an uncertain world, whether it’s business orthodoxy or the pace of technology, change is now the prime directive.
The more adept we are at change, the better we can live.
