Software developers agree simplicity matters, then build complex systems anyway
A heated online debate reveals the gap between engineering principles and workplace realities
Every software developer knows the golden rule, keep it simple. Yet walk through any technology company and you'll find systems so byzantine that their creators struggle to explain them. This isn't incompetence—it's something far more interesting.
Sean Goedecke discovered this when his seemingly innocuous blog post about "doing the simplest thing that could possibly work" exploded into one of the most contentious programming debates in recent memory. Over 350 developers rushed to comment, nearly all beginning with agreement before explaining why the advice fails in practice.
The response revealed a fundamental contradiction at the heart of modern software development, everyone champions simplicity whilst systematically building complexity. This isn't hypocrisy—it's evidence of deeper forces that make our industry's most obvious advice impossible to follow.
The false consensus
Goedecke's argument couldn't be more straightforward. Instead of designing elaborate, scalable systems upfront, developers should "understand the current system deeply, then do the simplest thing that could possibly work." Choose in-memory rate limiting over Redis. Single servers over distributed architectures. Add complexity only when genuinely forced to.
The principle traces back to Ward Cunningham and Kent Beck's Extreme Programming work in the 1980s, where they would remind each other during pair programming sessions to find the simplest possible approach. It became agile development orthodoxy.
Yet the discussion that followed revealed how impossible this "simple" advice proves in practice. A developer at a major tech company wrote, "Anyone proclaiming simplicity just hasn't worked at scale. Even the simplest business problem may take a year to solve, and constantly break due to the astounding number of edge cases."
Another shot back, "I have worked at scale. I have found countless examples of people not believing in simple solutions which eventually prevail and replace the big-complex thing."
Both were right. The disagreement wasn't about simplicity's value—that remained universal—but about what constitutes simplicity and when it's achievable. This reveals the first uncomfortable truth, simplicity means different things to different people with different constraints.
The career complexity trap
Dig deeper into the responses and a more troubling pattern emerges, developers rarely optimise for technical elegance alone. They optimise for career advancement, and complexity wins every time.
Resume-driven development dominated the discussion. Multiple commenters described colleagues who deliberately chose complex technologies not because problems required them, but because impressive solutions enhanced career prospects. One developer observed, "Most people using 'modern' web technology are built as if they were anticipating FAANG scale, not because they are, but because the people building them hoped to be working at FAANG soon."
The incentives are perverse but logical. Simple solutions demonstrate competence but not expertise. They solve problems without generating stories for promotion committees. Complex solutions, even inappropriate ones, signal technical sophistication to hiring managers who lack domain knowledge to distinguish necessary from gratuitous complexity.
Consider the promotion criteria at most technology companies, visible impact, technical leadership, architectural decisions. None reward the developer who prevents problems through elegant simplicity. All favour those who heroically solve complex problems—even problems they created themselves.
The organisational stranglehold
The most damning evidence came from developers who had attempted simple solutions within large organisations, only to watch them collapse under business pressure.
One revealing case involved a team that built basic reporting functionality—"a simple service sitting in front of a database." The system worked beautifully until business stakeholders discovered it. Each feature request seemed reasonable in isolation, export to Excel, user permissions, data filtering, automated alerts. Collectively, they transformed the elegant solution into a maintenance nightmare.
"They thought we could avoid months of work and keep it simple and instead caused years of mess because making breaking changes is extremely difficult once you have wide adoption," the developer explained.
This pattern repeats endlessly, simple solutions work until they don't, and organisations refuse to invest in proper refactoring once users depend on systems. Instead, they pile complexity upon complexity, creating what one commenter called "hacks stacked on top of hacks."
The organisational incentives seem designed to discourage simplicity. Engineering teams face relentless pressure to deliver features quickly, leaving no time for the deep understanding that simple solutions require. Business stakeholders reward visible progress over architectural quality, creating feedback loops that favour complex but impressive-looking solutions over simple but maintainable ones.
The experience paradox
Perhaps most intriguingly, developers' relationship with simplicity varies dramatically with experience—but not as you'd expect.
Junior developers gravitate towards complexity because they mistake it for competence. Having learned about various technologies, they want to demonstrate proficiency, leading to what one commenter termed "architecture astronomy." They genuinely believe sophisticated patterns signal good engineering, regardless of problem requirements.
Senior developers face the opposite trap. Their experience makes them acutely aware of potential future requirements, edge cases, and scaling challenges. This knowledge can drive premature optimisation, where they build elaborate solutions for problems that may never materialise. "I've seen unavoidable pain caused by over-engineering systems to prepare for several orders of magnitude more scale than current needs," Goedecke notes.
The sweet spot lies between these extremes, experienced enough to understand problems deeply, restrained enough to avoid over-engineering. This requires not just technical knowledge but practical wisdom about when complexity is justified.
One developer who rebuilt the BBC's sports platform provided compelling evidence. The existing system "consisted of several dozen distinct programmes instantiated into well over a hundred processes running on around a dozen machines." By ruthlessly applying simplicity principles, he replaced it with "a single JAR running on a single machine that ran 100-1000 times faster and was more than 100 times more reliable."
However, this transformation required six months of careful analysis before he felt confident tearing down the complex system. The simple solution demanded deep expertise to identify and considerable courage to implement.
The real lesson
The heated debate around Goedecke's post exposes simplicity's true challenge, it cannot be achieved through principles alone. Context, incentives, and organisational culture matter more than individual developer preferences.
The few developers who successfully implemented simple solutions shared common characteristics. They started with genuine problem understanding rather than jumping to solutions—what Goedecke calls "doing engineering." They possessed sufficient political capital to resist premature complexity pressure. They worked in environments valuing long-term thinking over short-term delivery metrics. Most crucially, they recognised that simplicity isn't complexity's absence but its careful management.
The most honest assessment came from a developer who wrote, "The longer I spend working in tech, the less optimistic I become about our collective ability to predict where a system is going. It's hard enough to understand where a system currently is."
This suggests the real value of "do the simplest thing" isn't as universal principle but as counterweight to the industry's natural complexity bias. In a culture that rewards intricacy and punishes restraint, even imperfect simplicity beats thoughtless sophistication.
The passionate response to Goedecke's seemingly obvious advice reveals a profound truth, developers understand the principle because they experience its absence daily. They agree simplicity matters not because it's achievable, but because without constant vigilance against complexity, they end up maintaining systems so intricate that nobody—including their creators—truly understands them.
The debate continues because the stakes are real, the difference between software that serves human needs and software that serves only itself.