As I said: I feel like there is something brewing - something we are not talking about. This is not about founders being fraudulent or VC firms gaslighting the public, although I suspect there is some amount of that going on too. There is a lot of talk about the “AI bubble” as of late. Anecdotally, it feels like a majority of people in tech agree/suspect that there is one. Even a substantial amount of folks who love LLMs and have close to completely stopped writing code by hand will admit that “something might pop” in the near future.

What I am wondering, however, is whether that is missing the mark. What if we’re not in an AI bubble - but a software bubble?

The great promises of AI

LLMs and the tools built on top of them are an obvious breakthrough in digital technology. Their ability to “understand” text is unparalleled, and using interactive dialogue with the end-user to research and understand topics is a great completement to reading the internet through Google. Especially since the years leading up to the release of ChatGPT saw an absolutely horrendous enshittification of what used to be a remarkable search engine.

The market hype responded accordingly. Nvidia, a company that literally creates one single kind of hardware, rose to become the most valuable company in the world - and AI-native companies like Lovable are valued at ridiculous sums after only a single year of existence.

The writing on the wall is clear: at some point in the near future, LLMs/AI will create more value for society than we can possibly imagine. Or, that’s what the investments tell us anyway.

The AI sceptics

The sceptics will tell you that all of this is a bubble:

• LLMs are not as good as they appear. They just feel like it because they are generating text, which creates an “illusion of intelligence”.
• LLMs, while they can surely generate code, cannot generate good enough code at a large scale to be truly valuable.
• LLMs are a crutch that let people avoid learning.

You have heard these takes before. Public figures bearish on AI think that the LLMs will fail to live up to the hype, and that the markets will crash. This is nothing new.

But that is not what is bugging me. What I am starting to wonder is this: What if there is nothing wrong with the capabilities of the LLMs. What if we are simply unable to build anything useful with them?

Let me explain what I mean.

The trajectory

Think of the significant software you use today. Then think about all the software you used 10 years ago. How much has changed? For me, not a lot. For work, I use Slack, Google Drive/Docs, Jetbrains IDEs for programming and Google Chrome for web browsing. I use Spotify for listening to music, Netflix for streaming movies and TV shows. On my smartphone, I use Facebook Messenger, WhatsApp, Twitter and Youtube.

In 2016, literally all of that was the same. The only new significant piece of software that has emerged in the past decade are the LLM tools.

Now compare that to the 10 years prior, between 2006 and 2016. In 2006, most of the apps listed either did not exist or were in their infancy. Smartphones had not yet hit the mainstream, there were no app stores. Google had not yet released a web browser.

TikTok is an obvious omission from my list (since I don’t use it) that actually was released in the past 10 years. But with the evidence that is connecting social media like TikTok with severe mental health problems in kids, and with the US congress even going so far as considering it a serious threat to national security, can we really call it useful?

If we look at the last 20 years, there seems to be an extremely visible plateau in the production of useful software. It appears that all our ideas for creating a better world using computers have stagnated. Famous software companies have either gone down the path of Microsoft and their laughably bad start with Windows 11, made extremely questionable choices like Apple with liquid glass, or they have done like Spotify, Netflix or Slack and arguably not changed a thing in 10 years ¹.

Now, you might think that I am being unfair. During the first of those two decades, an entirely new computer format (mobile smartphones) hit the market, and massive online ecosystems such as social media platforms were brought to life. It is only natural that there was significantly more software being built between 2006 and 2016 than the decade after that.

Also - LLMs and AI, you could say, is one of those new platforms. So just you wait. In 2036, you will have replaced all your software again.

But… does it look like we are headed that way?

AI for building new user experiences

Let us compare AI to the expansion of the internet or the release of the smartphone. The argument, then, would be that AI as a technology will enable entirely new ways to interact with computers, which will open the door to powerful, new ways to create value and improve the lives of people.

ChatGPT has been out for over three years now - and several of its open and closed competitors were not far behind. Have we seen that sweeping revolution in computer interactions spring to life?

In comparison, the iPhone was released in 2008 - and the App Store (including the tools to build your own apps) one year after that. In 2009, you had the very first opportunity to install custom apps on your phone - with apps like Spotify being available within weeks. By 2012, it felt like everyday computer interactions had radically shifted to be a mobile experience. Social media had become something you do on your smartphone, you could send money to your friends and family on the go, and various chat apps had completely replaced SMS.

With the exception of the actual big chatbot companies (OpenAI, Google etc) - where is all the amazing LLM powered functionality? Virtually all companies I see have tried - and for the most part the users all despise their attempts. Microsoft is being dragged in various online spaces for their attempts to squeeze Copilot into everything. Even famous AI-influencers (in the programming space) bemoan the use of AI in various products:

Every time I see an AI button in a UI somewhere I cringe and ignore it. Simultaneously I’m going nuts with my agents. Why is consumer AI so shit? https://t.co/6tVxCFCabR

— Armin Ronacher ⇌ (@mitsuhiko) January 11, 2026

I concede that the AI platforms themselves have successfully built useful products on top of these technologies. But so far, it does not appear to scale to the entire industry. Not in the ways the smartphone or the internet did, unless you are a “prompt your way to a website”-company like Lovable or Replit.

AI as a productivity tool

Another way people expect AI to revolutionize work is as a productivity tool. Especially as a means of generating code.

Sam Altman began his stardom as the face of AI by declaring his intent for AI to cure cancer or make novel discoveries in the field of physics. Despite these ambitious ideas, it looks like most frontier model companies spend the majority of their time shipping products dedicated to “agentic programming”. Tools like Claude Code have become so popular that even billioaire CEOs with business degrees seem to play around with them:

Watching Claude Code mass-murder backend tasks in seconds then spend 45 minutes misaligning a button...

... has given me more insight into the frontend vs backend engineer wars than a decade in tech. I used to think frontend engineers were being dramatic...

😂😂😂

— Sebastian Siemiatkowski (@klarnaseb) January 24, 2026

Last year was a bit of a watershed moment for LLM-assisted programming. With the release of Opus 4.5 and ChatGPT 5.2, a serious amount of independently minded software influencers changed their mind from “AI cannot write good production code” to “actually AI writes most of my code now”.

To me it looks like the tide is turning. Maybe this is not just an astroturfed fad that will pass in a year or two. Maybe most people will truly write code using “Agents” (or whatever comes next) in the near future. Heck, what if the models get good enough to simply help all of us write just as good code as we would write by hand - but at a significantly higher pace. If that happens, then the AI hypesters will have won, right?

But here is where I go back to where I started this article. Look at the direction we have been headed in the past decade. Will accelerating our productivity in said direction… actually lead to a lot of valuable software?

Even the most crazed, bullish AI influencers online are all about how “AI can write as good code as senior developers, but faster”. I rarely hear them talk about, or expect, that LLMs would transcend human talent and surpass us when it comes to software quality. Given that LLMs are trained on all of our existing code, making it become significantly better seems like a tricky problem to solve - if it is even solvable with the existing model architectures.

So if the wildest dreams of Dario Amodei come true, and we boost our productivity writing code tenfold, are we certain we won’t just spew out even more irrelevant SaaS garbage? Even more blur animations in our Finder windows that cause even harder frame rate drops? Even more addictive, attention-hacking software that ruin the brains of our kids and make them suicidal?

If AI is the productivity powerhouse that its proponents claim - are we actually in a place where we know what we would do with it? Or has software development seriously stagnated in the past decade? Maybe Casey Muratori is right when he says that it is ironic that we managed to get an AI that replicates our programming at a time when software development standards are at an absolute rock bottom.

Learnings from the internet and social media

While it is only tangential to my main point, I think it is fair to also compare the explosive rise of AI platforms to that of social media. There is something to be said about how the past two decades have been shaped by social media platforms such as Instagram, Twitter, TikTok, Snapschat and Youtube.

The companies behind all these apps have made an insane amount of money, all carried by the underlying micro-targeted advertising business model. The market value created by these companies is insane, as the software enables thousands of companies to use Google, Youtube, Facebook/Instagram etc to reach the perfect target audience for their products.

But there is an invisible tax that has been paid by the public, too. In the past decade, countless pieces of evidence has surfaced of the drawbacks of the algorithmic social media feeds - from whistleblowers inside the companies to research linking social media use to lower life satisfaction and erosion of trust in society.

As we speed-run our way to the AI dream world as imagined by the likes of Marc Andreessen, do we believe that the software we build today will help us reverse these trends? Or are we falling ever faster into a lonelier landscape filled with anime AI companions, robot-written blog posts and an ocean of auto-generated music on Spotify?

As I was typing this blog post, OpenAI literally announced their plan to insert ads into ChatGPT. Time seems to be a flat circle, and the internet still seems to have only a single kind of business model.

So why a bubble?

Let’s tie it all back to the title and what I mean by a software bubble. People talk about an “AI bubble” - telling us that the models cannot possibly become as good as the hypesters tell us they will be. But to me that is missing the point. The investments and valuations are not based on how high the next generation models will reach on various benchmarks - but rather what we would be able build using them. And from what I can tell, most of the proposed usage comes down to software; either by embedding it into our products or by letting it build our products for us. Both of those are based on the assumption that software product development is in a good place, and that creating more in the same trajectory will generate some kind of human prosperity. I… am not sure I feel like that is the case.

Maybe there is something else here - some elephant in the room not talked about on Twitter. Maybe there are some obvious ways in which generative AI can be incorporated into weapons manufacturing and that all the investments will be justified as soon as they get a contract worth 5% of the yearly Pentagon budget.

If not - where will it all lead? What is the end game?

Conclusion

This was a mixed bag of what obviously looks like AI pessimism. I am not a doomer in the sense that I think AI will become super-intelligent and erase us from the planet. It feels more likely that it will become the next iteration of social media: it will throw the likes of Lovable to fantasy-sized IPOs, and at the same time risk making our children less educated and more miserable.

I am also filled with hope, however. Hope that this time, maybe it is more obvious to us what is happening. Maybe we will get tired of Suno-produced music and Clippy 2.0 early enough to reject it. From the way people react to all the new AI-based features, maybe there is hope that people start chasing truly valuable technology instead?

Peter Thiel once said that “We wanted flying cars, instead we got 140 characters”. This was a condensed version of his criticism that in the past half century, we have made laughably little progress in the “world of atoms”. Instead, everything has happened in the “world of bits”. I honestly could not agree more.

Maybe, if we are in a software bubble, and it bursts - this could actually be great for software development as a field. Come to think of it, in the aftermath of the dot-com bubble, the broken remains of the software industry managed to create a tremendous amount of world altering products: Wikipedia, Facebook, Youtube, Gmail, Git, Skype, Google Maps and World of Warcraft…

Could we become that good at building software yet again?

Anybody who has written modern Javascript or Typescript knows that the web is built by people treating their prettier.config.mjs-files as if they were beautiful Bonsai trees. Programming without proper linting plugins to handle the preferred import order and formatting is considered as reckless as dumping radioactive waste in a local lake where kids go swimming in the summer.

And if you are a typical “backend developer”, surely you agree there are very good reasons for why you cannot let a “controller” have direct access to a “repository” without first crossing the service layer? Obviously, if some parts of your system are large enough to warrant a certain amount of architectural layers, then said layers must be applied everywhere else too? Thank God that we can enforce it with things like ArchUnit.

All of this to achieve a harmonious level of consistency across the codebase. Because said consistency obviously comes with improved readability.

…or does it?

As with anything related to software, there is hardly any science to back up any claims of one style being more readable than another. In fact, “best practices” in general are mostly held together by the figment of our collective imagination (although that is a blog post for another day).

How certain are we that consistency actually does improve our ability to comprehend what is written? I think a lot about what works for myself when I configure my editor. My preferred color schemes make code look like a Christmas tree; I want as much discrepancy between different syntactic and semantic elements as possible. Function parameters, local variables and class fields all have different colors? Love it. Global variables are in cursive? Amazing. Methods/functions are blue while member variables are white? That’s the stuff.

There is something about things being visually different that helps my brain subconsciously make sense of it without me needing to explicitly read and think hard about the tokens. Giving different constructs of the source code a certain level of salience helps me identify important things without contemplating every identifier or paranthesis.

Here’s how the creator of a particular font for dyslexic people describes what makes it simpler to read:

Designed by a dyslexic, the font focuses on legibility by enhancing visual distinction between characters, reducing reading complexity…

“Visual distinction” stands out as an interesting property of the font. That such a thing would help readability does feel rather intuitive.

Could inconsistencies be… good, actually?

Do you ever feel like you’re navigating a codebase where all the modules, classes and packages are so consistent that you struggle to even tell them apart? If every single piece of CRUD comes in identically layered web -> service -> repository -> domain model shapes, then the sheer weight of architectural harmony suddenly drowns out the discrepancies in the business logic.

But what if one didn’t need to have a single blueprint for all modules? What if every module could be slightly different, where the architectural sophistication grows from a necessity to accommodate for the unique requiements and complexity of the domain?

Could it possibly be quite helpful to open a package and notice that “this package only has an endpoints and a model file - it must be really simple”?

And with formatting - if certain files or modules turned out to look a little bit different - is it possible that it serves as contextual clues for the brain to tell things apart? Could certain styles help your brain identify the author of the code (your colleague), letting you more easily prime your brain to read the entire code the way they typically write it?

You could think of it as micro-dosing inconsistencies if you will. I’d like to think of them as the ability to navigate neighborhoods of identical houses based on what cars people have in the driveway, or how they have decided to decorate their front lawn.

Good use of consistency

As any good blog poster, I obviously make straw man arguments that support a rather weak take. The obvious benefit of some kind of auto-formatter is that formatting indeed does matter. Formatting is part of the puzzle when it comes to making code comprehensible. For instance:

• Lumping cohesive lines together with separating empty lines can create visible “sections” of a function body
• Leveraging indentation to indicate control flow (even if your curly brace-language doesn’t require it)
• Placing longer sequences of parameter arguments on separate lines to avoid them disappearing from the screen

And if it turns out that you have a team or an organization where people simply do not spend a lot of time thinking or worrying about formatting, then an auto formatter might absolutely outperform the median outcome without it.

Similarly - if you have a server application where different packages of similar size and complexity have completely different styles “just because”, then that obviously can hurt one’s ability to understand it. Words have meaning (or should at least), so when someone actually does decide to call something a “repository” or a “use case”, it is indeed useful if the name is a clue towards what it actually contains. And on the flip side, if every class is a “service”, then the word “service” has no meaning.

Where are you even going with this?

I don’t intend to suggest that these small inconsistencies are obviously and provably better.

I mostly for myself wonder whether there is actually a cutoff point where the use of all these automated tools, these rules about architecture and about naming, where they start working against their stated goal. And whether we are too blind to see it, because setting up the perfect automated code analysis pipieline just feels so good.

What do you think?

Before we go further, let me quickly demonstrate what we’re talking about. Extension functions are a neat little syntactic trick baked on top of an ugly, underlying JVM signature that makes for a nicer call site. This means you can do something like this:

// instead of this...
object AddressUtil {
    fun prettyString(address: Address): String {
        return "${address.street} ${address.streetNumber}, ${address.zipCode}"
    }
}

// ... with this butt-ugly call-site...
val string = AddressUtil.prettyString(address)

// ... you can have this...
fun Address.prettyString(): String {
    return "${this.street} ${this.streetNumber}, ${this.zipCode}"
}

// ... so pretty! It looks like the function is actually part of the Address type
val string = address.prettyString()

But this neat little syntactic trick has opened more than one of Pandora’s little boxes. There are obvious pitfalls like:

fun String.toLocalDate(): LocalDate = LocalDate.parse(this)

// wtf - it's so weird for `.toLocalDate()` to show up on auto-complete for ALL strings
"zuck@facebook.com".toLocalDate() 

But today I am not interested in small, ugly things like being able to parse Mark Zuckerberg’s email address into a date object. Instead I hope to persuade you that there is a larger problem that causes real damage to readability.

Pandora’s by far least favorite box

The following insight came to me when I was visiting KotlinConf this year, and I saw a talk related to library API design in Kotlin. There was this one bit in the middle of it, a comment made by the presenter, that triggered something in me. The full quote:

You can also add [Kotlin Extension Functions] to types that you own… And I also like to do that because it makes a clear separation between what is core in your class, and what is not. Another way to think about it is that you have classes for your data, and then you have extension functions for your code.

After I saw it said explicitly, it dawned on me that I see this pattern a lot in my professional life.

// people seem to prefer this
class Person {
    // this declaration only has the state
    var address: Address? = null
}

// and then place operations on said state elsewhere - sometimes in a SEPARATE FILE
fun Person.moveTo(newAddress: Address) {
    this.address = newAddress
}

// instead of just...
class Person {
    var address: Address? = null

    // boo - methods?! what is this, Java????
    fun moveTo(newAddress: Address) {
        this.address = newAddress
    }
}

When I talked to some proponents of this pattern, they tell me that what they like about it is that it becomes clean. The state is declared in one place, and the state transitions in another. This allegedly makes the code more tidy instead of everything being jumbled together. They point to the declaration of the type itself and all its state, and the pristine aesthetics of having only declared a block that resembles a struct in C.

Let us look a bit closer at the pros and cons.

The “benefits”

It is not a particularly hot or contrarian take to say that when people say “clean” what they actually mean is “code I like”. Most developers agree that it is of supreme importance that code is easy to read. Some people, of course, will make the case that code being “clean” IS what makes it readable. At the same time, the only way to actually prove that said “clean” code is actually easy to read would be to write the same program twice; once strictly with the pattern and once without, and then have several third parties try to interpret the code and somehow grade their ability to understand it.

The proposed benefits of this split is that it makes sense to only look at a type as what it contains, and filter away everything about what it does. This is meant to be less distracting when you simply want to know what properties something has, and vice versa.

Now, you might expect me to say that splitting up state and state transitions in separate files and motivating it by saying that it is “tidy”, “clean” or “nice” is doing something without real, provable benefits. That’s not enough however. I would go as far as saying that it is an emotional attachment to something that has glaringly obvious drawbacks.

The drawbacks

Splitting up state and state transitions, if you CAN keep them together, does not make any sense. It is a clear step away from writing cohesive code. Cohesion refers to the practice of squeezing things together that belong together - I struggle to find anything quite as cohesive as the state of a type and the procedures one can use to manipulate said state. They are always relevant together.

If you put all your code for a type in one place, then a single jump in your IDE takes you to all the things that type does. If you split them up, now you have to read multiple files at once to figure out the myriad ways the type can be interacted with.

Also, in this specific case, the only way for an extension function to actually mutate any state is for that state to be publicly mutable, undermining any attempt at information hiding or protection of invariants.

Programmers are obsessed with splitting things up

Imagine being a home decorator who thinks bathrooms tend to be over-furnished. There is simply too much going on in the bathroom. But then this professional has an epiphany! If we simply put the sink and everything that goes with it in another room, we will have a super clean toilet-only space, and a pristine sink-only space. Genius! Except… you know…

There is simply too much focus in software development on how to split things up. Be it modules, libraries, micro-services or whatever. I personally feel like the quest for separation starts in the wrong end. We shouldn’t be looking to find what things to spread out, we should search for what we squeeze together. Few things are as satisfying as when you want to change or extend a program, and quickly discover that all the things I need to touch are right here. After figuring out what parts to collapse into cohesive bits, the separation reveals itself as whatever is left.

Intuition comes first, strategic reasoning second

In his book The Righteous Mind, psychology professor Jonathan Haidt lays out an empirically observable trait of humans; that our opinions are primarily shaped by our intuition (emotions), not our reasoning. In other words, when we dislike something - it’s not because we came to the rational conclusion that we should - it is the other way around. We have some gut instinct either to like or dislike of something, and only if we are forced to defend our position do we start making up arguments. We let our intuition guide most of our decision making, and then let our internal press secretary (the reasoning part of our brain) explain our decisions after the fact.

Haidt calls this relationship the Rider and the Elephant. The elephant (our intuition) will mostly decide where it goes and what it does, and the rider (strategic reasoning) for the most part has to follow. To some degree, the rider can influence and actually convice the elephant to take an action against its own will - but these are rare events. This behaviour can be seen and measured when asking people to make judgment calls about things such as politics and morality.

One important aspect of our intuitive mind is that it rarely is built from rational thinking. Instead, it tends to be shaped by a combination of our genetics and our surroundings. If a person you look up to as an authority figure preaches a certain ideal, you are likely to build your own intuition around said ideal - without using any specific rational thought process.

I believe this model to be applicable to our preferences for software design patterns as well. I think the reason people decide to carve away functions and place them elsewhere is an “it feels good in my tummy” kind of situation. It looks so neat and tidy when types only have their properties, and no ugly methods to distract the reader. People then take this intuition, this aesthetic preference, and let their reasoning brain make up rhetorical talking points for why it makes sense. These talking points are then heard by large audiences (at KotlinConf), who themselves build an intuition - and the vicious cycle repeats.

Are there good uses of extension functions?

Absolutely. The most obvious case is the one even present in the name of the language feature: extension. Let us look at a simple example.

Imagine you have a module or a featureset you do not control, with some User type that has a birthDate.

// we use this, but don't control and can't change it
class User(
    ...
    val birthDate: LocalDate
)

Now we want to have some basic business logic that checks whether or not this User is old enough to vote in elections. Let us say this requires you to be 18. In regular Java code you might be forced to do something like this:

public class UserUtil {
    public static boolean isOldEnoughToVote(User user) {
        var age = ChronoUnit.YEARS.between(user.getBirthDate(), LocalDate.now());
        return age > 18;
    }
}

// usage
public void castVote(User user, Party party) {
    if (!UserUtil.isOldEnoughToVote(user)) {
        throw IllegalArgumentException("Try again.");
    }
    ...
}

But - this buries this logic check behind a Util type that one simply needs to know is there. Sure, maybe you will stumble upon it elsewhere and remember that it exists, but we can do better.

// you can also have "extension vals"
val User.isOldEnoughToVote: Boolean
    get() {
        val age = ChronoUnit.YEARS.between(birthDate, LocalDate.now())
        return age > 18
    }

// usage
fun castVote(user: User, party: Party) {
    if (!user.isOldEnoughToVote) {
        throw IllegalArgumentException("Try again.")
    }
    ...
}

This might not look like much - but there is one pretty amazing upside. It shows up in auto completion. This successfully lets your addition be closer and thus more cohesive with the User model.

People often talk about how important it is to be able to read code, but I personally would also like to stress the importance of discovering code at all. In large codebases, it can be very difficult to make changes and improvements without finding the right existing building blocks you are meant to incorporate.

So, wait - is this a rant about Kotlin or about humans and their moral tendencies?

I honestly don’t know. There is a larger story brewing within me on the theme of developers’ emotional and intuitive connections to the tools they use. Whether frameworks, languages or patterns become popular because they rationally solve a real problem - or whether they were presented at an amazing keynote by an industry celebrity that sparks an irrational wave of inspiration.

Today it came in the form of a rant at Kotlin - one day (if ever) it might be a long post of its own.

Don’t use an ORM - just write SQL

and what follows will be a standing ovation, virtual or in real life.

In my experience, your typical ORM hater is smart, productive and very influential wherever they work. That is why it has taken me so long to figure out whether I disagree with them, or if I am simply too stupid to have come to the same conclusion.

It was not until I heard that at least one more influential programming influencer actually DO see them as valuable that I begin to let myself defend them intellectually.

highly recommended even if you don't end up using it, lots of great & interesting ideas

ActiveRecord remains my favorite ORM, very pragmatic, stays out of the way & leverages OO in the right wayhttps://t.co/OIIT10GDiw https://t.co/DyeNU3Qml0

— htmx.org / CEO of SEO (same thing) (@htmx_org) November 1, 2023

The criticism

The hatred for ORMs is not unfounded. I would never go so far as to say that anyone who says their application became simpler when they tossed it out in favour of just writing SQL strings is lying. Lots and lots of of especially Java shops have been burnt on the JPA/Hibernate stove, and you will hear them complaining about:

• fighting weird, implicit N+1 performance problems
• debugging unexpected flushing and cache invalidation behaviours
• never truly understanding the correct combination of annotations to get their many-to-many to work

It is natural that they start to gag when an online guide is suggesting you pick it up “to avoid having to learn or write SQL”. But I feel like the popularized position of rejecting the entire concept of an ORM means throwing out the baby with the bathwater. I contend that the problem with ORMs is not the idea itself, but something else.

The problem

There are a couple of actual large problems with ORMs that I will totally admit.

Use an ORM to not learn SQL

This is a terrible idea. If you are using a relational SQL database, then learning how that SQL database works is key. Gavin King, the creator of Hibernate, even has this to say about Hibernates relationship to its underlying database:

Indeed, systems like Hibernate are intentionally designed as “leaky abstractions” so that it’s possible to easily mix in native SQL where necessary. The leakiness of the ORM abstraction is a feature, not a bug!

ORMs were always meant as a tool to help expressing parts of your database interactions, namely state transitions, while intentially letting you also interact with the database in other ways where raw SQL outperforms the ORM in ease-of-use.

Gavin later in the same comment goes on to say:

I speculate that the problem is not that ORM gets in the way of using SQL, it’s rather that so many Java/C#/Ruby/Python/JavaScript developers don’t have a strong enough knowledge of, or aren’t sufficiently comfortable with, relational databases and the relational model. That is emphatically not the fault of ORM!

I find this a little less convincing. If anything, the design of the tools are often going to encourage a specific kind of usage. If we are in a place where people frequently use ORMs in a way they were never designed to be used or, then it can of course very well be that the tool itself is not very self explanatory.

I suspect there might be another culprit, however…

Hibernate

Most of the ORM complaints I have heard come from people fighting with Hibernate specifically. I have spent my time working mostly on the JVM, which means it could just be a sampling bias, but I rarely hear people complain about Rails’ ActiveRecord the way they do about JPA/Hibernate.

I respect this criticism. Hibernate is by no means the most obvious way to implement an ORM. Any ORM is going to have a layer of “magic” between the code and the underlying SQL, but said magic comes in different flavors.

The way this magic works in Hibernate/JPA is that any so-called @Entity in Hibernate is “observed” from the side by an EntityManager, where the EntityManager reads the annotations of the entity class and attaches the appropriate behaviour. This model deeply obfuscates what actually happens in the entity lifecycle, as all the “what actually happens” stuff is tossed far away from the actual entity definition.

It doesn’t help that Hibernate is perhaps a bit TOO flexible when it comes to defining relationships. Entity relationships can be both eager and lazy, and can have intricate “cascade” rulesets, which define whether creating/updating/deleting one entity should automatically trigger a similar write on another. It also has both @OneToMany and @ElementCollection annotations, which both are some kind of one-to-many, and I myself don’t really fully understand the difference.

The combination of all these attributes, together with the fact that all of them are “operated from afar” by an EntityManager, means that it is hard to create some kind of intuition regarding how it actually all works. It is of course extremely well documented (otherwise it would never work at all), but good documentation can’t compensate for an unintuitive model.

ActiveRecord on the other hand, and my recent JVM favorite Kotlin Exposed, are both inheritance based models, where your ORM data models inherit from some base class, and interacting with the state of your object means said changes propagating down to some underlying mechanism. In Kotlin Exposed, the “magic” that happens in my ORM classes can be found by simply using “go to definition” in my IDE. Inheritance gets a bad rap these days, but it is in fact a pretty appealing choice for building a simple 80/20 ORM.

Spring Data JPA

The dominant application building framework on the JVM is Spring, and more recently Spring Boot. Boot specifically (inspired by Rails) is a “convention over configuration” library which helps you set up a “sane defaults” configuration to quickly get going without having to make too many choices upfront.

One particularly fateful, cursed decision made early in Spring is to make JPA and Hibernate its default, and in many ways only, batteries-included library for working with the database. This is unfortunate, because it forces people to opt-out of using JPA to interact with the database, rather than opting-in to using it once they are convinced that an ORM could work for them in their domain.

In Spring Data JPA specifically, not only are you often using Hibernate, but Hibernate is also encapsulated inside the Domain Driven Design-inspired repository-pattern of Spring Data - which hides the EntityManager entirely. So not only are you dealing with the already quite obscure EntityManager, but now all of that hides behind another layer of repository interfaces with proxy-implementations generated at runtime.

I don’t think the desire to create a happy-path setup for database interaction is a bad idea, but when it comes in the form of Spring Data and JPA/Hibernate, I admit one has good reason to be disappointed.

When can ORMs shine?

ORMs let you express several database tables as a single object graph. For many complex OLTP systems, the ability to encapsulate state transitions underneat a single object is a real help.

Imagine you have an model that encapsulates a complaint made by a customer to some company. Imagine one crucial state transition of this complaint is “closing” it, when it is considered handled by your support staff. In a real world application, changes like these are usually non-trivial. Let us imagine that we have the following things that need to happen in our database:

• The complaint needs to be marked as closed_at = now()
• A complaint_event needs to be inserted expressing that it was closed
• If there are any complaint_task entries that are still unresolved, we wish to add another complaint_event expressing that
• If there are any complaint_task entries marked as escalated, we reject closing altogether

Using some hypothetical ORM, the code would typically end up looking like this (using Kotlin):

class Complaint {
  private var closedAt: Instant? = null

  private val tasks: OneToMany<ComplaintTask> = OneToMany()

  private val events: OneToMany<ComplaintEvent> = OneToMany()

  fun close() {
    val hasEscalated = tasks.any { it.isEscalated }
    if (hasEscalated) throw IllegalStateException("Can't close complaint with escalated tasks")

    val hasUnresolvedTasks = tasks.any { !it.isResolved }
    if (hasUnresolvedTasks) {
        events += ComplaintEvent(complaint = this, description = "Complaint closed with unresolved tasks")
    }
    events += ComplaintEvent(complaint = this, description = "Complaint closed")
    closedAt = Instant.now()
  }
}

in this model, all the rules related to closing are protected inside this function. The pattern, when used like this, encourages expressing multi-table state transitions and invariants deep down on the “database type” itself, right next to the database column declarations. This achieves really high levels of Locality of Behaviour.

Without the use of an ORM, the same code ends to look something like this…

class ComplaintService(
    // dao == "data access object"
    private val dao: ComplaintDao
) {

    fun closeComplaint(id: String) {
        val tasks = dao.findTasksByComplaintId(id)
        val hasEscalated = tasks.any { it.isEscalated }
        if (hasEscalated) throw IllegalStateException("Can't close complaint with escalated tasks")

        val hasUnresolvedTasks = tasks.any { !it.isResolved }
        if (hasUnresolvedTasks) {
            dao.addEvent(complaintId = id, description = "Complaint closed with unresolved tasks")
        }
        dao.addEvent(complaintId = id, description = "Complaint closed")
        dao.updateComplaintSetClosedAt(complaintId = id, closedAt = Instant.now())
    }
}

class ComplaintDao(
    private val database: Database
) {

    fun findTasksByComplaintId(complaintId: String): List<ComplaintTask> {
        return database
            .query("SELECT * FROM complaint_tasks WHERE complaint_id = ?", complaintId)
            .convertTo<List<ComplaintTask>>()
    }

    fun addEvent(complaintId: String, description: String) {
        database
            .update("INSERT INTO complaint_event (complaint_id, description) VALUES (?, ?)", complaintId, description)
    }

    fun updateComplaintSetClosedAt(complaintId: String, closedAt: Instant) {
        database
            .update("UPDATE complaint_event SET closed_at = ? WHERE complaint_d = ?", closedAt, complaintId)
    }
}

… if you are lucky. If you instead work with people who would rather write DAO functions for hasEscalatedTasks or hasUnresolvedTasks, then you will have even more specialized methods on he second class.

In a real world application, I tend to see that the latter “just write SQL” pattern tends to come in two shapes:

• Either whatever code is run inside the Service just executes SQL directly…
  • This in order to avoid excessive layering (which I am a fan of!)
• … or all common queries and updates are placed in a single DAO type like upstairs
  • This in order to have reusable database interaction functions

Both of these styles fail to capture the strengths of the original ORM one. Splitting things up in more layers can cause the “separation of concerns problem” where code must be read across multiple files to be understood. The DAO facades tend to get so big and hyper-specialized that you often find yourself always adding new functions for anything you write, creating an ocean of functions that have all their filters and joins in their name like findAllTasksWithOutcomeAndBlockersWhereIsNotDeletedAndComplaintId.

But most importantly, the ORM pattern creates a single place where you more or less HAVE to add state changes to, which means you also need to review how your addition or change affects the other rules of said type. In a “just write SQL” world, it is not uncommon for a new addition to the code to simply ignore any other attempts at controlling the lifecyle of data by just adding new update functions from the side. None of these patterns make either possible or impossible, but ORMs definitely is stronger at co-locating the state itself and its changes.

What about querying?

Notice how I did not mention reading data a single time in the previous section. That is on purpose. ORMs are pretty convenient when doing basic reading too. If most of your system can be expressed in terms of reading an updating singular “objects”, then using an ORM for querying works splendidly as well.

But virtually all people who hate ORMs with a passion can recall debugging a performance problem where they fetched multiple objects from the database using an ORM, and tried their best to query them efficiently or maybe updating some of them in batch. Suddenly, what is trivial when “just writing SQL” becomes nearly impossible with the ORM. That’s true - because ORMs are not designed to perform large, complex querying or batch processing.

But Fredrik, quite often one has to do that - doesn’t that mean ORMs are a bad fit almost always?

I mean, that’s exactly why ORMs are designed as leaky abstractions by design. If you need to make complex queries, then just bypass the ORM. That’s the whole point. ORMs are there to help you express complex changes of the data, while still letting you operate freely with the database on the side. Every single ORM I have encountered bakes in raw SQL access in its public API, without having to set up a database connection from the side.

In the Complaint example of the previous section, it would make perfect sense to:

• Use the ORM for interacting and working with a single complaint in your system
• Use SQL to generate charts and reports for open complaints

In sum

If you find yourself in a business domain where complex state transitions on singular types are rare, then it makes perfect sense to never even consider an ORM. If you deal with huge imports of mostly immutable data, batch processing of information or running complex queries on large datasets using Hibernate, then yes you are going to have a bad time.

But a lot of us actually DO make complex state transitions on singular data graphs. And some of us do use ORMs, and we are doing fine.

Also, if you just hate all ORMs with a passion, then that’s fine. Enjoy your findUnresolvedPaymentsWithCustomerDataAndAccountInformationFromLastMonth functions!

one day code base understandable and grug can get work done, everything good!

next day impossible: complexity demon spirit has entered code and very dangerous situation!

The “next day impossible” is not only a funny expression. In the interview he talked of the experience of seeing a system grow beyond ones ability to comprehend it in just a matter of weeks.

That a simple system slowly evolves into a complex one through incremental additions of features, bug fixes and tweaks is a mystery to no one. But what are the kinds of changes that can break one’s mental model of the workings of a system within just a couple of weeks? I will argue that I have an example of such a thing.

Implicit data modeling

One thing we constantly do when programming is creating data models - be it in APIs, in the database or elsewhere. This is the bread and butter of working as a software developer.

Let’s give a simplified example of a real-world scenario I have experienced (more than once!). Imagine our system has a User type stored in the database with an id, name and email. Imagine we don’t store any password, because the user instead logs in by getting a one-time-password sent to their email.

One interesting aspect of models like these are the things they convey that are not explicitly written down or reflected in some data contract - but are rather implicitly assumed. One common case with all User-types like these is that they were all created when somebody decided to “sign up” to our platform. That implies that all the entries in that database are customers that signed up for our service. From that, the following assumptions are probably safe to make about those people:

• They have gone through some kind of signup or onboarding flow
• They all had to accept some kind of “terms and conditions” as part of signing up
• They are aware that they are in fact one of our customers

A wild feature appears

Now let us introduce a feature request. The growth side of the company believes that more people would sign up and start paying for our product if they could get a nice, free, demo of the app. Therefore, they would like to send marketing emails with a link where people can get straight into the demo mode.

“Easy!” says some developer. “If we simply create User entries for their emails, they will be able to log in. And to keep track of whether they should see the demo or the real experience we give the user a new column called type which is either real or demo. Let’s ship it!”

Even in a real world scenario, this kind of change to a model can often rapidly be built and shipped with not that much code. And at a first glance, the addition was totally backwards compatible, right? All the existing Users presumably had their type value set to real, and thus we wouldn’t corrupt any old users.

Except - what about those implicit assumptions about the model? Suddenly we have a pool of users that no longer match our existing mental model. What if:

• Some team works with cross-referencing our own data with data found in external sources and uses “Do we have a User with that email” as a proxy for “is that email a customer of ours?” They will now have tonnes of false positives.
• Some team uses the changes of the user table to track growth of the company customer base? Suddenly it might look like you grew way more than anticipated. If you’re lucky you’ll catch it - but if the change is too subtle then you might show the wrong numbers to stakeholders.
• This size of the growth hack campaign even outnumbers the size of your customer base? What if you had 10k users and we sent 20k emails? Suddenly your user table grew by 200% and what used to be the only type of user is now in the minority. With an addition of this size, a small problem can turn into a large one if the work required to restore it is proportional to the amount of “demo users”.

Adding a completely new way of creating User has potentially broken the mental model a lot of your colleagues had. In a sense, the change turned out not to be backwards compatible at all. To adjust for it, lots of other integration points might be forced to be updated with an extra where type = ‘real’ filter to restore the previous behavior. If you are a small company and you quickly identified all 3-5 of those integration points - great! If you are a bigger company, and you actually are not even aware of the existence of some teams who depended on the old behavior - uh oh…! Chances are that they won’t know of your change until much later when they’re starting to see “weird errors coming from the users API”. Maybe the change in this crucial integration point has done some form of “irreversible damage”, such as accidentally sending emails to non-customers.

Not to mention the fact that future feature additions now have to take demo users into account. Additions that might have fit naturally into the old version of the model might suddenly feel awkward in the new one.

What else could have been done?

The original bet was that “if people could try our platform out in a demo mode, then maybe they would be impressed enough to buy it”. Another approach here would be to identify a small, isolated subset of your product and simply copy-paste it into a stateless version that can be used without logging in at all. In other words closer to something like an “interactive mockup” that looks and feels like the real deal, but is more of a temporary playground. If it turns out users would like to keep their playground-work after signing up, you could potentially “import” that data into the real model after a successful signup.

This might mean doing a little bit more work upfront, and it might force you to keep two UIs up to date for now. But the upside is real. This kind of solution is way less likely to “leak” to the rest of the system and teams - and if it turns out that the demo mode turned out to not work, then simply deleting this copy is dirt cheap. In contrast, cleaning up the demo users could be expensive if their presence has had ripple effects in the system.

In summary

In my experience, it sometimes takes very little code to make a rather drastic change in a model. This category of changes, which breaks the mental picture people might have of the model, can very rapidly induce a massive amount of complexity into a system. All with a very modest change.

You might think that the real problem here is that people shouldn’t make implicit assumptions about data models at all. There is some truth to that, but it’s not a particularly useful opinion in a fast moving environment where everyone is doing their best. In the real world, people will make these kinds of assumptions all the time, either consciously or subconsciously. A lot of the time, such an assumption will work well enough and let a team build something useful for your customers. If you are maintainer of the part of the system that holds the User table, it is much cheaper for your team to think twice before shipping an expansion of your model, than it is for everyone else at the company to be paranoid about what you might do.

Do with that what you will.