(This is meant to be the first entry of a series which will cover individual points more in depth. We’ll see how that goes.)

We’re the tech industry. We have ideas. We have ideas all the time. And we’re used to turn our ideas into applications.

So, how does it go… here’s the back-end component… here’s the front-end component. We’ll write the former in Python, or perhaps JavaScript, to optimize for prototyping. After all, we have so many ideas, we need the ability to iterate quickly. Sprinkle in a few dependencies, that will speed us up. Oh, and let’s use ChatGPT and Copilot, we’ll be even faster. Oh, and performance, yeah, performance: microservices, Kafka, Redis, Kubernetes… we’re now ready to scale up. Oh, Sentry, Prometheus and Grafana, too, where would we be without ’em? For the front-end, we’ll write a website, and for mobile, Electron.

Oh, wait a second, we need to make money and to fidelize our users! Let me see… ads, tracking, and good reasons to revisit our app, perhaps a little NFT here, gamification… alright, we should be good.

Three… two… one… and we have shipped v1!

Also, the world is burning.

Perhaps it’s time we revisited how we do things?

The Infinite World Model

For the past ~30 years, the software industry has progressively optimized itself for an infinite world. An ever-increasing number of customers. Ever-increasing CPU and GPU power. Ever-increasing bandwidth. Ever-increasing Cloud power. Unlimited energy. For open-source projects, unlimited untapped contributors. For everyone else, unlimited VC money. Also, governments that either do not care, do not want to harm economic growth, or do not understand.

That’s the Infinite World Model and, truly, we owe it to a combination of 19th century Colonialism (unlimited raw materials and labour) and the Industrial Revolution (unlimited raw power and progress).

In this Infinite World, the main imperative is to be able to seize the opportunity:

For most companies, these factors trump everything else. They trump hardware costs. They trump maintenance costs. They trump bandwidth cost. They trump battery usage. They trump security. They trump accessibility. They trump privacy. They trump democracy. They may very well trump local or international law. And they definitely trump both ethics and technical debt. While we’ve been complaining about the result, we have spent the last 30+ years teaching developers (and product managers, and CEOs) to ignore all these. After all, Worse is Better, right?

And once the VC money comes, or the users come, there will be time to fix things. But of course, you have probably experienced it: once money comes, there will be time to add new features. Fixing things can wait until it becomes an emergency, or forever.

If you pay attention to actualities, you may realize that this world might not be around much longer. For one thing, we’re in an Energy Crisis and a Climate Crisis that has a direct or indirect impact on both industry and consumers. A Logistics Crisis. A few Addiction Crises. A worrying Consolidation of Power among few unreliable Tech Giants. There’s a strong risk of crisis on multiple raw materials and components. There’s also that Trade War that isn’t in the news anymore but never actually stopped. When I was at Mozilla, we started seeing the end of these unlimited open-source contributors. CPU performance per core has largely stalled since 2010. Did I mention that we’re in a Financial Crisis and that VC money has rather dried up for startups that do not have “AI” in their pitch? Also, we have Democratic Crises but governments look like they are finally moving on tech, for better and for worse. Oh, and of course we might have stepped into World War III without quite realizing. That’s bound to disrupt things quite a bit, in fun and interesting ways.

We can bet that things will get better. And for all we know, it might. I, for one, am not confident.

So I’m going to assume that the model that worked for the 19th century aren’t necessarily fit for our time.

Towards a Finite World Model

How do we build for a Finite World?

Let’s perform a quick Risk analysis:

That’s… actually much bleaker than what I intended to write when I started working on this blog entry. Our Finite World sounds like a paranoid dystopia, doesn’t it? In fact, it looks like the entire Cyberpunk genre, minus flying cars. As usual when dealing with Risk, we’ll hope that none of this will happen but plan ahead in case it does.

Since we’re talking Risk, let’s give our Threat a name. Let’s call it the Zerg. We live in a Finite World. Energy, disk space, food, attention, democracy, public health, society or peace are all finite resources. And we have the Zerg. Anything that eats away at our Finite World without giving us something at least as valuable in return, getting us closer to exhausting, bombing or coughing our way back to the stone age, is a Zerg.

Our mission is now to fight the Zerg, as aggressively as we need.

We’re the tech industry. We might not be able to solve climate, or energy, or food, but we have power. Power to do inadvertent harm, certainly. But power to do some good, too.

A Zerg rush, as illustrated by MidJourney

Designing for a Finite World

I’m not going to pretend that everybody can fight the Zerg. In particular, if you live in an authoritarian state and if your only choice is to comply with the boss’ order or starve or be deported, your hands might be tied too hard to do anything from this side. Note that you might still have a choice as a consumer, which is better than having no power, and I suggest you consider the best way to use that choice.

From this point, I’m going to assume that you have influence beyond being a consumer. Perhaps you are a developer, or a researcher, a decision-maker, or an advocate, or an entrepreneur. Let’s explore a few ways to use that influence and design against the Zerg.

Designing for Finite Needs

Alright, let’s start with a hard one.

You have an idea. It’s going to make a great start-up. It’s going to make you rich.

Congratulations. Please consider dropping it. No, seriously.

We’re talking about a Finite World. I know, I’ve been in start-ups and the ecosystem is exhilarating, is makes us feel smarter, in control of our life, possibly in permanent burnout, but we’re learning and achieving so much, plus we have a chance to strike rich! But the start-up ecosystem is designed as a permanent Zerg Rush. We’ll have to give it up, eventually. It’s time to start saying goodbye.

This goes double if your idea is based on another Zerg, such as blockchains or generative AI or social networks or adware or viral marketing or AAA video games or anything that requires addiction to sustain a business. Yes, some of these are insanely cool things. But by design, they require exponential amounts of resources to evolve, which makes them Zergs.

This does not mean that you should abandon research projects or art projects or hobbies. But it does mean that you should strongly consider not scaling them up. Sorry, I meant not Zerging them up.

Designing for Finite Funds

There are a few, rare, ideas that do need to scale. They are going to do so much good that they are going to outweigh the Zerg factor. If you have one, cherish it, feed it, grow it, fight for it, make it real.

But whatever you do, do not take VC money. If you are familiar with VC investors, you know that the system is designed to burn your hands with money into consuming as many resources as it takes to go big or go bust. In other words, to turn you into a Zerg. Perhaps some day, VC will evolve into something new and that fits our Finite World, but we’re not there yet, and no amount of “green” in the name or description of your VC will be sufficient to change that.

Alternatives exist. Bootstrapping. Open-source. Working with universities or non-profits. Self-funding the effort as a side job. None of these alternatives is as well-oiled as the VC money pipeline. They take time and effort. They can fail. Still, they remain better than the alternative.

Designing for Finite Performance

Expensive energy and hardware means that we need to stop considering performance as “we’ll throw in more cloud resources” or “we’ll run on more recent user hardware” and return to considering performance as “we’ll need to use high-performance languages/libraries” and “we’ll spend more time benchmarking”. This is true both on the front-end, on the back-end and on the wire. And since you don’t have VC money to spend on cloud resources, you’ll need to do this quite early.

In other words, to fight the Zerg, reconsider common wisdom and benchmark aggressively every component of your architecture.

I am not going to suggest you give up on using the Cloud, because it is not clear to me that alternatives are better with respect to the Zerg. If you have insights on the topic, please get in touch.

Designing for Finite Data

Expensive disk space, fragile democracies, hostile communities, stricter laws and higher chances of being hacked mean that we need to stop considering storage as both free and without consequence.

Again, let’s start with the hard one:

Let me stress this, because, in a Finite World, you might be endangering people’s lives with your data. If you cannot run your business without endangering people’s lives, please consider pivoting.

Now, we can proceed with the usual Zergs:

In other words, as much as you can, benchmark your Zergs into harmlessness.

Similarly, I am not going to suggest leaving your data off the Cloud, as I do not have a clear alternative to suggest. But do not hesitate to investigate.

Design for finite Brainpower

Everything is expensive. Your API provider might be your competitor and might price you out any day now. Working and hiring across borders has gotten more complicated. Science and tech education might be under-funded and lacking. Achieving performance takes time. You might be struggling to hire developers. You will need to work with less.

This might be counter-intuitive, but it means that you need to take time and invest it into using technologies that work for you in the long run.

Again, this might be counter-intuitive, but I would also suggest against using ChatGPT, Copilot or any other AI assistant. For one thing, each request to ChatGPT or Copilot has a steep energy cost. For another, experience suggests that junior developers (and other professions) use the results without understanding it, which in turn hurts both the Maintenance and Knowledge objectives above.

Fighting back the Zerg

So far, everything we’ve discussed was about slowing down the Zerg. And if we, as an industry, only succeed at massively slowing down the Zerg we’ve been mass-producing for 30 years, that will already be a victory to celebrate.

I want to believe that we can go further. I’m not going to pretend I know how. But maybe you do.

What now?

I hope that this post can inspire some in the tech industry to take arms against the Zerg. I know that I am going to use this and push for better Zerg fighting at work.

Undoubtedly, I have missed many ideas, many possibilities. Undoubtedly, I have been naive about many things, too. But we need to start somewhere.

I’m planning to revisit some points of this post and dive into more details. After all, I’m supposed to be an expert in safety, performance and open-source, it’s time to put that knowledge to good use, isn’t it?