Why tech keeps solving the same problems in circles

Tech hype cycles are not innovation. They are memory loss. IBM's Holly Cummins delivered this thesis at QCon London, arguing that the industry keeps rediscovering the same architectural tradeoffs because engineers fail to learn from history. Her talk, "The Free-Lunch Guide to Idea Circularity," draws a direct line from Victorian sewage engineering to modern microservices debates.

The core claim is uncomfortable: most "new" patterns in cloud architecture, AI infrastructure, and distributed systems are repackaged solutions to problems the industry already solved decades ago. The difference is that today's engineers often lack the institutional memory to recognise them.

What does the Great Stink have to do with microservices?

Cummins opens with London's 1858 sanitation crisis. The Thames had become an open sewer for 2.5 million people. Michael Faraday described "feculence rolling up in clouds so dense they were visible at the surface." Parliament, housed in a new building on the river, couldn't function because of the smell.

The problem was pure throughput. The river lacked capacity for the transaction volume the city generated. This is not a metaphor Cummins deploys casually. She calls it a "pooput problem" and connects it directly to the scaling challenges that dominate modern architecture discussions.

The crisis had a direct cause: an architectural decision made 20 years earlier. London had eliminated cesspits, the hollowed-out areas beneath homes where waste accumulated. On paper, removing cesspits was obviously correct. Nobody wanted them. But the replacement system, routing everything to the Thames, created a worse failure mode at scale.

“Near the bridges the feculence rolled up in clouds so dense that they were visible at the surface.”

— Michael Faraday, 1858

This is the pattern Cummins wants engineering leaders to recognise. A reasonable architectural decision, made without understanding future scale, creates a crisis that forces expensive remediation. The 20-year sewage reconstruction that followed, including the Thames Embankment, solved the immediate problem. But the decision to eliminate cesspits had seemed just as sensible at the time.

How debt compounds across dimensions

Cummins extends the debt metaphor beyond code. She identifies four types of debt that accumulate in engineering organisations: financial debt, technical debt, epistemic debt, and sleep debt. Her argument is that these categories interact in ways leaders underestimate.

Financial debt in tech has a specific context. The zero-interest-rate period (ZIRP) that ended in 2022 changed how companies approached infrastructure investment. When capital was cheap, organisations took on architectural complexity they couldn't sustain once money had real cost again. The microservices boom of the 2010s coincided exactly with this period.

Technical debt is familiar to most engineers, but Cummins frames it differently. The debt doesn't just slow delivery. It erodes the organisation's ability to understand its own systems. This creates epistemic debt: the gap between what the system actually does and what the team believes it does.

Sleep debt, the least technical of the four, matters because exhausted engineers make worse architectural decisions. And those decisions compound into the other three debt categories. A team running on insufficient rest will accumulate technical debt faster, document less (epistemic debt), and be more likely to approve shortcuts that create financial obligations.

Why the same patterns keep returning

The talk's central provocation is that "nothing is new under the sun" in tech. Cummins, a Java Champion and Senior Technical Staff Member on IBM's Quarkus team, has worked across full-stack JavaScript, build architecture, JVM performance, and innovation leadership. Her observation is that each of these domains recycles ideas the previous generation abandoned.

Consider the shift from monoliths to microservices. The industry presented this as progress. But the problems microservices solved, deployment independence, team autonomy, technology flexibility, had previous solutions. And the problems microservices created, distributed tracing, network reliability, data consistency, were problems the monolith architecture had avoided by design.

Now the industry discusses "modular monoliths" and "right-sized services." These are not new discoveries. They are the middle ground the microservices hype cycle skipped over.

Cummins maps this pattern to AI infrastructure. The current generation of AI tooling faces scaling problems that distributed systems engineers solved years ago. But because the AI engineering community has different roots, those solutions are being rediscovered rather than applied. The upcoming InfoQ webinar "Why AI Agents Fail at Scale: Context Is a Data Layer Problem" scheduled for August 27th, 2026, addresses exactly this gap.

What engineering leaders should do with this

The talk is not nihilistic. Cummins offers a constructive frame: embrace sustainability and revive proven engineering disciplines. This means treating architectural decisions as bets that will need to be revisited, not permanent solutions.

Documenting why a decision was made matters as much as documenting what was decided. The cesspit elimination in 1830s London made sense given the assumptions of the time. The problem was that nobody recorded those assumptions, so nobody could evaluate when they stopped being true.

For teams adopting AI infrastructure, Cummins' framework suggests studying how previous generations handled similar scaling challenges. The "new" problems of context management, state persistence, and transaction boundaries have extensive prior art in database engineering and distributed systems. Ignoring that history guarantees repeating it.

The presentation is available on InfoQ, including the full 42-minute video and downloadable slides. For engineering managers watching their organisations adopt AI tooling, the historical parallels Cummins draws are worth the time.

The uncomfortable question

If tech hype cycles are predictable, why do organisations keep falling for them? Cummins doesn't answer this directly, but her debt framework suggests one explanation: the people who remember the last cycle's lessons often aren't in the room when the next cycle's decisions get made.

This is epistemic debt at the industry level. The knowledge exists, but it doesn't transfer. Each generation of engineers inherits systems without inheriting the reasoning behind them. When those systems become painful, the "solution" is whatever seems newest, which is often what the previous generation abandoned.

The fix is not to resist all change. It's to ask better questions before adopting it. What problem does this actually solve? What problem did the previous solution solve? And what assumptions would need to change for this cycle to end the way the last one did?

Source: InfoQ