I'm angry today and need to write about it but not ready to make a blog post. So here we are.
I feel trapped in tech. Part of which is just because it's the only way I've made money for the 20 years of my working life. Even before I was working as a Software Engineer I was a help desk tech, which hardly seems like a thing to go back to.
But there's something else. There's a ... circularity in the software industry that I can't seem to get outside of. So I want to talk through it. I have a hard time describing the self-reinforcing system concisely but I'll try. Software companies want the engineering work to be closely measured and optimized because engineering is a cost center. However, engineers do not drive the development cycle. That work is, in my experience, always driven by the Product org. The product org not only rarely measures their feature impact or contribution to release timelines rigorously, but also is systematically incentivized to grow the software such that the experience degrades until customers flee the product. (For details on lack of rigor in product vs engineering, see Appendix A.)
I saw something that set me off recently and it was almost precisely this. I saw a toot from Rebecca Wirfs-Brock, who I very much respect, talking about how exactness is important if you're building software that should reflect physical laws or model financial transactions, etc. I find myself thinking, how relevant is this to the actual complaints that software engineers and managers face day-in and day-out? I suspect it is rare and I think that is because most software development is no longer related to modeling of formal systems. There was a shift from building systems that plot missile trajectories to building systems that move business workflows online. The former is a formal thing that can be modeled and proven correct. The latter is an attempt at market capture through a fuzzy process of intuited need. I often find myself wondering when this transition took place. If I had to throw a dart, I would say it was the late 90s and early 00s. Business strategy became approximately "have you tried rubbing a computer on it?" by the mid 00s.
Any for-profit software business wants to maximize revenue as a profit-seeking entity. Fine. The best way to do that is pursuing market dominance in some space and then establishing a monopolistic Landlord-Tenant business model. SaaS loves recurring revenue, as does everyone in business. Build a good moat and once you get the users, all you have to worry about is turning screws to juice revenue. Everyone knows this. Sooner or later you overdo it in pursuit of better growth metrics or more customer acquisition, break workflows or enshittify the experience and start slowly bleeding former customers. But it's immensely frustrating to see the cycles play out with those same customers going to some newer SaaS provider that is earlier in the lifecycle and just not at the "enshittify to juice numbers" stage of monopoly. It happens over and over as if one day a company might actually "get it right" and not eventually frustrate their own users into leaving.
This keeps happening. And we see industries spend billions and waste person-years of worker time adapting to a new tool that every decade or so. I'm amazed Slack hasn't jumped the shark yet. Figma and Miro are in the "peak health" stage of this cycle where they are solving more problems than they are creating. People are flocking to Bluesky because it "feels like old twitter" failing to remember that the same effects that incentivized twitter to collapse will ruin Bluesky in due course.
It is clear that if you can't run the software yourself, the company running it can pull the rug out from under you whenever leadership feels the current state of affairs "just isn't good enough". It is clear that if you don't control your own data, then any attempt to migrate to a less onerous alternative is potentially more expensive than advantageous, trapping you in the rentier business model. A major part of the reason the Rebecca Wirfs-Brock post bothered me is that it focuses on the wrong things. Exactitude (or correctness, generally) in software only matters so much when the system requirements change every 3 months as product teams wildly flail trying to figure out how to capture more marketshare.
Software exists in a social context. See this.
All software is an exercise in power dynamics. See that.
But it doesn't have to be this way. There are a host of technologies that enable local-first software and peer-to-peer communication models. Yet companies have no incentive to pursue them. Most engineers don't even know they exist because no one is hiring for them. Why would you bother? You can't make a billion dollars building software that way. And so the industry goes on, building another generation of things that will not last.
My company doesn't care if I know how to build things in a way that are resilient. It doesn't matter if I could build a solution that a client could run locally and that would let them retain control of their information because that would be actively bad for the company. And maybe too much hassle for the client to manage! The customer is disincentivized from becoming proficient enough to manage their own technical solutions because the industry continues to build more and more complicated ways of delivering software solutions. And so engineers don't learn these technologies either, because it is from a career perspective a waste of their time. The technologies do not become popular.
Earlier I was trying figure out how to categorize software based on how ethical it was. Moving from most unethical to least, the buckets I came up with were: Free SaaS (you/your data are the product), Paid SaaS (market dominance is the product), Paid "local" software (you own your data and compute, but locked in), Free Software (you own data, compute + code, good luck), and "Dynamicland models" or things that try to remove the need for specialists at all. To quote Bret Victor:
Computing must be reinvented in a form whose inherent complexity is so radically reduced, communities can build their own computing environments, for their own needs, with minimal dependence on vendors, specialists, and centralized production. It must be distributed through ideas and abilities, not products and services.
There are many people I love in this field. People for whom computers promised creativity, community, and autonomy. The longer we have been in the field, the more jaded we have become. There is a previous generation of dreamers, before my time, such as JCR Licklider or Dan Ingalls, who imagined that computers would become liberatory technologies. Whether they imagined that it would give people more individual autonomy and make it easier to resist centralized capital or not, they did believe that there would be a broader base of computing expertise and that the path to customizing your computer to serve you would be a more gradual and approachable process. They spoke of "bicycles for the mind" and a high power-to-weight ratio for enabling human freedom and exploration. That world has not, and will not, come to pass.
The "users" do not want to use their computers more. They want to pay someone to manage the computer for them and get on with their lives. The computer being intractable, miserable, stealing or entrapping their data, becoming algorithmically hostile due to the whims of a billionaire, and one day forcing them to learn an entirely new process to achieve the same ends is an expected outcome. An unfortunate eventuality. But it is preferable to years spent learning how to make it work "right".
I work in the salt mines of this industry, where we pretend what an individual engineer does matter, and where corporate leaders insist that if we build our software right, it will make the world a kinder and better place. We pretend that we serve our customers because the truth is too embarassing.
I could go round and round for hours about this. But the problem is the same. I tire of trying to figure out how to optimize for "the wrong things". I know that what I build day in and day out will not last in the long haul because the true purpose of the software is a sort of information and process arbitrage. No one in the software industry is bothered that what we build won't last more than 10 or 20 years. Somehow, that isn't seen as our fault, or our problem. We don't provide a service, we exploit a local discrepancy in workflows and network effects to print money until we annoy the shit out of people.
I don't have an answer here or a satisfying end. I'm just frustrated and would like to build something that lasts.
The mismatch here is that while Product wants serious estimates from Engineering for the "build" portion of the product lifecycle, there is little meaningful effort to hold the Product org to the same standards in terms of measuring output. Because the work of understanding the customer need / desired impact and designing a solution is seen as inherently less formal / more abstract and squishy, the design step prior to engineering iterations is undermeasured and underscrutinized. But this won't come as a surprise to anyone.
Still, there is a lot of frustration whether I'm an engineer or a manager at being tasked with optimizing a component in a system whose major issues lie outside of my control. As a manager, I'm very aware that the business processes that incentivize new product development over our bug backlog are not the fault of the Engineering department. I'm aware that modernizing our frontend to enable more streamlined communication with Design will speed new product development but not fix a lack of formality in our goal-setting or product planning processes. And yet, we are supposed to measure. Measure sprint velocity, estimate tickets for domains and contexts that no one on the team has experience with, improve test coverage and standardize on-call rotations to minimize incidents and outages. We are intended to be deeply data-driven and metrics oriented.
hi brit. what a place this is to meet. this crawlspace hidden several strata deep inside the rotten yet still ticking innards of a shambling commercial behemoth proudly chasing many of the ill ends you so rightfully despise in your piece.
there's a Quaker tradition of saying "this friend speaks my mind" as a way of thumbs upping someones spirit-laced ejaculation in the midst of silent worship. I don't really have much more to offer in the way of critique. I can pull some thought strands though and see what kinds of mess my brain sweater makes when it unravels.
I think there's a framing issue lurking in here and I think Dynamicland suffers, perhaps fatally, from it. It's a framing of "the things that are making us soft hearted programmers sad" as a problem around computer use and software design. We want to engineer a solution--yes, that's what Dynamicland is, even if it purports an end state that destroys the need for computing professionals (like that promised end state of international communism we can just get to if we stay the course)--that fixes a system fundamentally. That's what we are trained to do and how we're trained to think.
I want instead to consider what counter examples might be to the kinds of massive enshittified nightmares every company seemingly becomes; the first one to come to mind for me is neocities.org. My friend runs it and we've talked about it at length. If you really squint it's paid SaaS. Web hosting + editing/creation tools + access to a community of creators. The fatalist logic of capitalism says that this thing should be enshittified by now.
however, neocities is not enshittified. Kyle grew it to a level of income that could sustain him and just...dug in. He works hard but not on growth. He works on sustainability and safety and hardening with no expectation of getting paid more than he needs to have a comfortable life in an affordable midwest city. It's just a rails app. No technological marvel had to be invented and no paradigm had to shift for the computer part of neocities. It succeeds because of restraint, clear eyes, and a commitment to sustainability. Meanwhile, his users are happy and enjoy using a site that is idiosyncratic, ungross, cute, social (but not in the bad way).
I find it very inspiring. There are other examples out there (newsblur, some eurorack module builders...I'm blanking on more and you can't really google this kind of thing). The lesson for me, here, is that...computers were never and are never the point. It's about human need or human want and finding a way to meet it (using a particular, possibly rarefied skill set) in a symbiotic way. Capitalism, sure, but...not the big C one? Maybe the little c one? Constrained capitalism? Symbiotic capitalism?
This is the kind of bazaarism or bodegaism or marketism that crops up in every human society of a certain size. It is only the ego inflation--subconscious, for the most part--of getting to ride hypergrowth rockets on the back of our CS degrees that makes us forget that our place as journeyman is at a stall selling small soft wares directly to the people who want/need them.
I've had a few ideas for little guys like neocities -- small ideas with users who show up for the "vibes," if you will, kept around by a very small team digging in for a long haul of ungrowth and living wage.
To me, it rings as an answer to this plight. My answer since github has been hiding out at the IA which is working for me but it can't work for everyone. I've always wanted to make something with friends and always decided not to because I felt like the choices were hypergrowth or an embarrassing death in a dark corner. That's just not the case though. Start small, rely on word of mouth, stay small.
I guess that's a big pile of brainthreads after all. Apologies if I've taken your essay in an orthogonal direction.