Two Dimensions of Software Complexity
When developers debate which software is most complex, they usually mean technical complexity: architecture, performance constraints, failure tolerance. But there is a second dimension equally worth examining: human complexity, meaning the political, cultural, legal, and social forces acting on the people who build and maintain the software.
Kernels, web browsers, and ERP systems make for a revealing comparison across both.
Technical Complexity
A web browser is several complex systems welded together: a networking stack, an HTML/CSS rendering engine, a JIT-compiled JavaScript runtime, a security sandbox, media decoders, WebAssembly support, and some more systems, all handling an effectively infinite variety of malformed and adversarial web content in real time. Chromium sits at around 37 million lines of code.
The OS kernel is comparable in size (Linux is around 40 million lines) but operates in a far more constrained environment. No garbage collection, no safety net, no abstraction layer beneath it. A kernel bug can silently corrupt memory or take down an entire system. The difficulty is less about breadth and more about the cost of being wrong.
ERP systems like SAP dwarf both at reportedly over 100 million lines of code. But lines of code are not a reliable measure of complexity: a million lines of tax rules and a million lines of lock-free kernel code are not the same thing. Most of SAP's bulk is domain complexity, encoding tax law, fiscal calendars, multi-currency consolidation, and industry-specific modules. Technically tractable, but vast in scope.
Human Complexity
Kernel developers are a small, elite, self-selecting community. They write for machines and fellow engineers. The social contract is clear and stable: any change that breaks an existing userspace program is considered a kernel bug, regardless of whether the program was doing something technically incorrect. Pressure is real but contained. This assumes open source kernels like Linux; commercial kernels like Windows NT kernel carry significantly more regulatory and organizational pressure by virtue of having a single liable vendor.
ERP software sits at the intersection of almost every human pressure imaginable. A bug in tax calculation may not crash a program, but it can trigger audits, fines, or legal liability. Every implementation touches finance, HR, logistics, and sales simultaneously, meaning every department has opinions and the power to derail a project. The software must encode completely different assumptions about how business and law work across dozens of countries. And the users are non-technical people whose livelihoods depend on the system working.
Perhaps most telling: decades of informal workarounds, spreadsheet patches, and undocumented exceptions get fossilized into requirements that make no logical sense but must be preserved. When ERP projects fail, and they fail spectacularly, companies lose millions and people lose jobs.
The Browser's Unique Position
The browser sits in a curious middle ground. Its core engineering teams are small and technically elite, much like the kernel world. But it carries a distinctive human pressure that neither kernels nor ERP systems face: it is the most politically contested piece of software in existence.
Every new HTML, CSS, or JavaScript feature goes through standards bodies where browser vendors, big tech companies, and advocacy groups fight over the direction of the entire web. Millions of developers publicly pressure vendors over slow feature adoption. Antitrust regulators scrutinize browser decisions at a governmental level. Accessibility, privacy, and security communities all have legitimate claims on how browsers are built.
Both kernels and browsers score similarly on organizational politics, but the nature differs. Kernel politics is mostly internal: maintainer hierarchies, subsystem ownership, and corporate interests from Red Hat, Google, and Intel influencing what gets merged. It stays contained within a technical community. Browser politics spills outward into standards bodies, public developer communities, and government regulators, making it more visible even if not necessarily more intense.
The kernel is not entirely insulated from regulation either. Kernels deployed in medical devices, vehicles, and avionics fall under strict safety certification frameworks, which is reflected in the table below as low but non-zero regulatory exposure.
Browsers and kernels also share one hard constraint: neither can break existing behavior. But the pressure manifests differently. Kernel breakage pressure is quiet and severe, surfacing through bug reports, distro maintainers, and enterprise contracts. Browser breakage pressure is loud and public, playing out in blog posts, conference talks, and viral complaints. Same underlying rule, completely different human texture.
Summary
| Kernel | Browser | ERP | |
|---|---|---|---|
| Technical complexity | |||
| Technical depth | Extreme | Very high | Medium |
| Codebase size | ~40M LoC | ~40M LoC | 100M+ LoC |
| Human complexity | |||
| Organizational politics | Medium | Medium | Extreme |
| Non-technical user pressure | Low | Medium | Extreme |
| Public and political scrutiny | Low | High | Low |
| Regulatory and legal scrutiny | Low-Medium | Medium | Very high |
The kernel demands the most technical precision. The browser is the most politically loaded. ERP is the most human.