DEV Community

Cover image for Most Software Is Just Glue Now
Austin
Austin

Posted on

Most Software Is Just Glue Now

The uncomfortable truth

Most software is not interesting anymore because most software has become predictable. The default unit of software now is the web app, the dashboard, the SaaS workflow, the AI wrapper, the Spring Boot service moving JSON between vendors. You can often guess the product before the demo starts. You can guess the stack before the engineer opens the repo. You can guess the pricing page before marketing publishes it. Predictability kills interest.

Software used to feel like a frontier because it forced contact with the machine. Even ordinary products had to reckon with memory, files, sockets, protocols, operating systems, compilers, deployment targets, latency and failure. You were negotiating with constraints, and that negotiation gave the work texture.

I came up through Java, which is nobody’s idea of romance. Java is verbose, conservative and ceremonial. It has interfaces, packages, build files, classpaths, dependency injection containers, thread pools, garbage collection, long stack traces and frameworks that can turn a simple endpoint into a hostage negotiation. The ceremony had a point. Java forced seriousness. It made you think about boundaries, contracts, types, transactions, lifecycle and the cost of change. A good Java service was a system, or at least it aspired to be one. That distinction matters because much of modern software feels like a template.

Everything became a web app

The industry spent 15 years pushing everything into the browser. Desktop software became SaaS. Native applications became Electron shells. Internal tools became React front ends over databases. Consumer products became authenticated dashboards. Many AI products are chat boxes, embedding pipelines, background jobs and subscription checkouts.

The sameness is hard to unsee. There is the TypeScript front end, the component library, the backend service, the relational database, Redis, object storage, auth, payments, queues, observability tooling and a row of third-party APIs holding the product together like duct tape under a countertop. The deployment target is the same. The interaction model is the same. The failure modes are familiar. The business model is familiar, too.

A lot of software today is a billing relationship with a user interface. That line sounds cruel, but cruelty and accuracy often sit closer together than we like. Some of this software is valuable. Some of it runs real businesses. Some of it deserves to exist. Still, the software itself has become less like building a machine and more like arranging rented services into a subscription business. It is efficient, and it is usually not interesting.

Java makes the problem obvious

Java is a useful witness because enterprise Java has always loved patterns. A typical Spring Boot service has controllers, DTOs, services, repositories, entities, mappers, configuration, exception handlers and tests. Much of that structure is useful. Often it is the right boring choice. The trouble starts when the structure replaces thought.

A service can look professional before it contains any real product insight. The packages are clean. The annotations are familiar. The logs are structured. The health check is green. The controller accepts JSON, calls a service, persists through a repository and returns a response. Moving JSON through five layers is not automatically engineering. Sometimes it is ceremony around a thin idea.

This is where modern software starts to feel hollow. A lot of development has become convention management. Choose the framework. Follow the pattern. Add authentication. Add billing. Add pagination. Add retries. Add audit logs. Add role-based access control. Add a Slack integration and call it a platform. The work can be hard, important and expensive to get wrong. Hard work alone does not make the result interesting.

AI caught us being boring

AI caught us being boring. Ask an AI tool to generate a Java REST endpoint and it will produce the expected parts: controller, request object, response object, service, repository, entity, mapper, exception handler and tests. It knows the shape because we made the shape predictable, and that should bother us.

AI does not need deep understanding to imitate a large amount of what now passes for software. It only needs the conventions. The naming patterns. The layers. The annotations. The shallow test that proves the mock was called. Before AI, implementation gave a project legitimacy. Someone had to build the screens, write the endpoints, model the data, wire the integrations, handle permissions, fix race conditions and deploy the product. Labor made the thing seem substantial.

AI weakens that claim. It can scaffold an application, draft a migration, generate boilerplate, write shallow tests and connect APIs well enough for a demo. It does not need to be excellent. It only needs to make implementation look cheap. If AI can generate most of your app, maybe your app was mostly boilerplate. That is an indictment of the software AI can mimic.

The scariest code is fake-clean

The danger is that AI-generated code often looks better than it is. Traditional bad Java code usually announces itself through the 900-line service class, the circular dependency, the mystery utility object, the anemic domain model, the catch-all exception handler or the transaction annotation in the wrong layer.

Generated code fails with better manners. It looks idiomatic. It uses the right annotations. It imports the expected libraries. It names things reasonably. It includes comments. It may even include tests. At a glance, it appears designed, but appearance is not architecture.

A senior developer learns, usually by being paged, that the hard part of software is preserving invariants as the system changes. It is knowing where state lives. It is understanding what happens when the queue is delayed, the provider is down, the retry runs twice, the transaction boundary is wrong, the cache is stale, the migration half-applies or the user does something reasonable that nobody modeled. AI does not remove those problems. It often hides them until they are expensive.

This is a new form of technical debt: unearned coherence. The code looks as if someone made decisions. In reality, it may only reflect the statistical memory of decisions made elsewhere, by people who had different problems. Fake-clean code might be worse than ugly code because ugly code at least has the decency to warn you.

Managed services turned codebases into traffic cops

The web-based SaaS model compounds the problem by outsourcing consequence. The database is managed. The servers are managed. Authentication is managed. Payments are managed. Search is managed. Email is managed. Analytics are managed. Increasingly, intelligence is managed, too.

This is not a moral failure. Nobody should rebuild infrastructure just to feel alive. Managed services made small teams more capable than they used to be. The trade-off is real. When every serious subsystem is rented, the product can lose its technical identity. The codebase becomes a coordination layer: configuration, REST clients, message consumers, ORM mappings, feature flags, security filters and adapters around vendors.

Many Java systems now live in that role. They route requests, enforce policy and translate between services owned by someone else. There is skill in keeping that reliable. There is discipline in making it observable and maintainable. The more value lives outside the codebase, the less interesting the codebase becomes. A surprising amount of modern software is just glue with a pricing page.

Interesting software still exists

Software is not dead, and the interesting work is still there. Databases are interesting. Operating systems are interesting. Compilers are interesting. Graphics engines, simulation tools, distributed systems, security tooling, embedded systems, local-first applications, scientific computing and developer tools remain rich areas of work. Java still has serious problems worth solving: high-throughput services, concurrency, profiling, garbage collector behavior, bytecode, distributed messaging, API design, correctness under load and systems that must run for years without collapsing under their own abstractions.

That is not where most of the industry’s attention goes. The center of gravity is web-based SaaS: thin clients, managed infrastructure, API orchestration, compliance checklists, growth loops and AI features added whether they belong there or not. That is why so much software feels dull. A new dashboard is not interesting. A chatbot is not interesting. An AI wrapper is not interesting. Another Spring Boot service with five layers and no domain insight is not interesting. Another product that routes text from one API to another and calls itself a platform is not interesting. Software is no longer interesting by default.

The answer is higher standards

The answer is higher standards. Build software that has a reason to exist beyond being easy to ship. Build tools with strong opinions. Build systems where correctness matters. Build applications that can work offline, respect user data, expose real power and survive vendor churn. Use the computer for more than rendering a form over a remote database.

For Java developers, that means treating a service as more than a collection of endpoints. Build real domain models. Define invariants. Be explicit about transaction boundaries. Make failure visible. Design APIs that can survive versioning. Use boring technology when the problem is boring, but do not mistake boilerplate for architecture.

Implementation is cheaper now. Scaffolding is cheaper. Boilerplate is cheaper. The shape of software is cheaper. Judgment is not. Understanding a domain is interesting. Choosing the right constraints is interesting. Preserving correctness under change is interesting. Making a tool feel inevitable is interesting. Owning the consequences of automation is interesting. Creating something that could not have been produced by averaging the last 10 years of web apps is interesting.

The future belongs to people who know what should not be generated. Software is no longer scarce. AI made that obvious. Good software was never just software. It was taste, constraint and understanding made executable. That remains rare, and rarity is where interest begins.

Top comments (0)