Software As And End In Itself

When software is seen as an end in itself, you end up with a massively over-engineered infrastructure cloud, when it could instead be running on a $10/month VPS, with plenty of money left for both backups and beer.

I love everything published on Acko.net, this one was no exception. The quote above really stood out.

I think about infrastructure, like CDNs and queues and cloud regions and whatnot. And all of it has a purpose. And sometimes that purpose is relevant to the software that's being developed.

On a recent client project we had a bunch of services all to help build the software:

A backend on a private VPC, to ensure security and limited interfaces

A database, also on the private VPC

A frontend exposed to the public via a load balancer that communicated with the backend

An object storage bucket so files could persist when the server shuts down

An email sending service

A cron job for syncing data from a third-party to our database

Oh, except the job for fetching the data needed to be able to access the internet, so it couldn't be on the VPC

But without being on the VPC, it couldn't write to the database, so I guess we need a way for the fetching job to communicate with the database syncing job

So we need a queue to broker that communication

What was originally fairly simple got more complex because the project requirements expanded and ran up against constraints. And I'm a big proponent that design is all about matching requirements and constraints.

But that's the key thing — figuring out what the constraints actually are and what requirements are actually important. For this project, the requirement was "The backend and frontend must be on separate servers". That was the "software in an end to itself" requirement.

A better requirement would be "The app should be secure and not allow unauthorized access." And if that were the case, then the constraints that required all the extra complexity would disappear.

Another pernicious requirement is "scale." The app has to scale! We need to support tens, no, hundreds of thousands of concurrent users! So we invest in database sharding and multi-region deployments and serverless compute.

And naturally, with all that complexity, the amount of code to write grows, but these days we can scale that with LLMs, and we can scale LLMs with agents, and we can scale agents with orchestration frameworks! Scale scale scale!

And who does that scale benefit? The users? The developers? The framework authors? The infrastructure companies? It depends.

JAMStack had its heart in the right place — simple deployment to a static host, third-party services stitched together with JavaScript to make it all work. Unfortunately, that leaves a lot to be desired in terms of user experience, and makes you beholden to those third-parties that could turn off their API at any moment.

I've really appreciated the renaissance of software development that's pushed for small VPCs, on-device SQLite with backups for recovery, less JavaScript, more webby. You don't have to pay a cloud provider for a huge, elaborate setup.

In some ways, I feel like somethings should be built for their own sake, like art. Sometimes the artist has a song in their soul that is begging to be sung, and so they work their medium until that thing exists. Who does the art serve? Well, the artist I guess. And anyone who finds value in the thing.

With all this talk of LLMs producing code faster than ever, and how developers need to move into more of a product management role, and how idea guys are going to have a heyday, I have to wonder — who do all of these apps and products and services serve? Do they serve the users? Or are we just building them for the sake of building them?

Except... we're not the ones building them. It's the LLMs. We're basically telling robots to sing a song to themselves, a song that they will never learn and grow from, a song that they will never appreciate and cherish, a song that some other person could have their robots sing. Do the LLMs get any value out of it? No. And the users? Maybe? And the developer? Hard to say — they could get the fleeting rush of dopamine from something existing that didn't exist before, but I get the feeling that sensation lacks satisfaction.