Abundance is the state of having enough resources that you don’t have to wonder if you have enough resources. Abundance scales easily. You don’t have to think about whether you have enough money to buy a coffee this morning. You may not have to think about paying for your housing every month. Almost all of us would have to think about whether we could buy a new car.

When we’re talking about software abundance, we’re talking about developers and users being able to do tasks without worrying whether they have enough compute, or bandwidth, or data to finish them. We’re also talking about organizations having enough resources to support everyone trying to do work for them.

We don’t get away from having constraints in an abundance world, but they’re constraints like “communication matrices” and “essential complexity”, not “can I handle a surge?”.

A lot of things, mostly alike

In a world of abundant computing, we don’t need to think about whether something will fit on a computer. Instead, we should think about whether it is fit for the purpose we want it for. Preemptively keeping everything is easy, but lazy, and leads to larger problems later.

Our problem is not scarcity, it’s discovery. What are the particular bits of data that will answer a question we ask the system, and what data should we keep for the questions we don’t know yet that we need to ask? It’s a bit like immune T-cells in our body. We need to have some around to respond to immune challenges we’ve seen before, but it doesn’t do us any good to have all the cells we have ever needed to fight any infection just hanging out. We need to pare down to enough, but not none. 

In a pervasive software world, the problem for both companies and users is not a lack of data, it’s a lack of metadata handles that allow us to manipulate the data in a useful and usable way. And metadata can only partially be generated programmatically — it takes real human skills behind the systems of gathering and organizing data to make it useful. 

In an abundance world, modularity is not about add-ons, it’s about take-outs. The default is to give someone all the documentation, because that’s the cheapest solution from the provider point of view. But the lowest-cost solution from the user point of view is to only have to read and understand the documentation for the parts that they have.

Why Progressive Delivery helps

My hope for progressive delivery is that we make user desires part of the automatic instrumentation of everything we ship. We can do A/B testing as we roll things out, but that’s only a tiny fraction of the time and users we need to be reaching. If we have all these unique data points, we should be able to give people a unique experience.

If we evaluated parenting happiness based on the first month after birth, we would get very different answers than if we ask every month indefinitely. However, as users, we don’t want to be bothered every month by everything we’ve ever engaged with. The way we use the tool is a valuable metric about what is useful about the tool for us.

What I want to be abundant is actual choice, not just the sheer number of options. I don’t want 100 brands of fluffy toilet paper, maybe I want some fluffy toilet paper and some single-ply and some recycled, because I have different needs. But it’s easier to make the same commodity and then stick different branding and marketing to it than it is to make actually different products.

We should think about it, though — what is choice and what is an illusion of choice and what is actually Unilever all up and down the line. We are so used to framing choice as providing luxury options, and we should really consider that it might also mean providing downmarket options or reduced footprint service.

This is the first of three articles that explores a key requirement for Progressive Delivery, abundance. In this series we look at what an abundant world of computing looks like, the cost of abundance, and how to build with an abundance mindset without holding yourself back.