The Free-Lunch Guide to Idea Circularity

Most technology arguments are conducted as if one side is correct. Dynamic or static, centralized or distributed, monolith or microservices, build or buy. Holly Cummins' argument is that none of these have permanent answers, because each is a trade-off whose balance point is set by external conditions. When those conditions move — hardware, interest rates, deployment models — an idea everyone had confidently dismissed becomes fashionable again, and it feels like a free lunch rather than what it is: the same trade-off, retilted.

Cummins is a Senior Technical Staff Member on the IBM Quarkus team and a Java Champion; her background spans full-stack JavaScript, build architecture, consulting, JVM performance engineering, and innovation leadership. The published transcript ends at the speaker's conclusion and contains no audience Q&A, so nothing in these notes is drawn from a question session.

These notes report what Cummins presented. The small amount of background added for readers unfamiliar with a reference is explicitly marked.

What You Will Learn

• Why "nothing is new under the sun" is a practical engineering heuristic rather than a piece of cynicism, and how to use it to spot opportunities.
• How a 19th-century London sanitation failure maps onto a centralized-versus- distributed architectural trade-off.
• Why the tech industry's hype cycles are structurally produced by venture capital incentives rather than by technical merit.
• Why Jevons Paradox predicts that AI coding tools will increase, not decrease, the total quantity of software and software work.
• How interest rates — not GenAI — line up with the developer hiring data Cummins presented.
• What ecological, financial, technical, epistemic, and sleep debt have in common, and why Cummins collapses all five into a single definition.

The Great Stink as an Architecture Review

Cummins opens in 1858 London. The Thames was effectively a sewer, and that summer was hot: water levels dropped, the sewage warmed, and the waste of 2.5 million people was moving through a channel with nowhere near the required throughput. She quotes Michael Faraday describing the feculence rolling up in clouds dense enough to be visible at the surface, and Disraeli calling the river reeking with ineffable and intolerable horrors. The event became known as the Great Stink. What finally forced action was that Parliament's new building became unusable because of the smell — the money that could not be found before was suddenly found, and a twenty-year sewerage programme began, producing the Embankment (with plumbing running through it to carry waste out of central London) and the pumping stations, including Crossness, which Cummins admires as technology we no longer build to that standard.

Her point is not the history. It is that the Great Stink was a throughput problem caused directly by a prior architectural decision. About twenty years earlier, someone had a genuinely good idea: eliminate cesspits. A cesspit, she notes, is a real architectural feature rather than only a metaphor — a hollowed space under a house where everything unpleasant accumulated and stayed. A law replaced cesspits with plumbing, and that plumbing discharged into the Thames. Good idea followed by good idea, and the result was worse.

Neither of the first two options is appealing, which is why the eventual fix had to be a different kind of solution rather than a swing back along the same axis. Even the first proper implementation only moved the discharge about six miles outside London before dumping it in the Thames again; a second iteration finally treated the sewage. Cummins presents this shape — good idea, consequence, swing back, and eventually a genuinely new synthesis — as the recurring shape of architectural change in software.

Ideas That Keep Coming Back Round

Cummins sets up the section with the line she prefers to "history repeats itself": history does not repeat itself, but it definitely does rhyme. She then works through several cycles where the idea itself never really changed; only the surrounding assumptions did.

Grid became cloud. Grid computing was fashionable, went away, and nobody thought about it again until it returned under a new name.

Dynamic became static. Java's conventional wisdom was that doing things dynamically and delaying decisions was good, and popular libraries did enormous amounts of work via reflection, which is an expensive way to do it. She generalises the point: the conversation the industry keeps having is whether to decide dynamically or pre-decide, equivalently whether to initialize lazily or eagerly, and she stresses that there are obvious benefits to both. Cummins is clear that the dynamic answer made sense at the time, for good technical reasons — Java is statically typed but almost everything else about it is dynamic. Cloud changed the assumption. Inside a container, your runtime environment is not going to shift meaningfully in terms of what is available on the class path, so the dynamism buys much less. Quarkus, the project she works on, challenged that accepted wisdom and pre-decided work that Java frameworks traditionally deferred to runtime.

She presented measurements of carbon as a function of load comparing Quarkus with another framework she declined to name on the slide but identified verbally as Spring Boot. Reading her graphs: a longer line means higher throughput and a lower line means a better carbon footprint, and Quarkus produced a long, low line — a correlation between being faster and being greener. A second experiment scaled instances up to meet load and showed Quarkus on the JVM as substantially more efficient than Spring Boot for running a Java application. (Writer's note, not stated by the speaker: these are the speaker's own project's benchmarks, and framework-versus-framework carbon comparisons depend heavily on workload, tuning, and configuration. Treat the direction as her reported experimental result rather than as a settled general finding.)

Distributed became centralized, repeatedly. Roughly fifteen years ago the industry swung hard towards distributed architectures and arrived at microservices as the hyper-distributed extreme, buying resilience and independent lifecycles at the cost of higher latency, more complexity, and more infrastructure spend. Cummins is explicit that this is not a clear-cut trade-off. Around the same period Git arrived promising decentralization, and that promise lasted a very short time before GitHub demonstrated that people quite like a centralized place to put source code — and became enormously successful doing it.

The same question is live in AI infrastructure. The large companies are investing hundreds of billions in data centres with, in her assessment, questionable ROI. Apple is taking the other branch: not building its own data centres, not building its own models, licensing them for a fraction of what running a data centre would cost, and putting AI capability into hardware instead. Rather than spending on the order of $100 billion on data centres, Apple sells us devices and we run the machine learning workloads ourselves. We get shiny products; Apple gets paid for the privilege of hosting its compute.

Sustainability as a Recurring Trade-off

The oldest recurring idea Cummins names is destroying our home, periodically interrupted by the idea that perhaps we should not. The cycle persists because there are real reasons to optimize for the short term as well as real reasons to be sustainable.

Her claims about scale: the tech industry is responsible for more carbon than aviation, which is usually treated as the poster child of climate irresponsibility, and data centres alone consume as much electricity as a medium-sized country such as the UK. This matters to engineers specifically because engineers write the things that run in those data centres.

Low-carbon energy is necessary but insufficient, because zero-carbon energy is not impact-free. She uses the Itaipu Dam in Brazil to show landscape impact, and notes it is not even the largest dam. The Three Gorges Dam moved so much water that — like a figure skater raising their arms — it changed the earth's rotation, lengthening days by 0.06 microseconds and tilting the earth's axis by about 2 centimetres.

So consumption must also fall, and she highlights two old, easy, effective techniques:

• LightSwitchOps — turn things off when you are finished with them, the way you would flick off a light. The reason nobody does this is experiential: many of us have turned a computer off and found it never worked the same again, so we learned not to touch anything that is currently working. Her prescription is architectural rather than behavioural — build systems that tolerate being turned off.
• Efficient software — the Quarkus result above is her worked example that performance work and carbon reduction can be the same work.

Hype Cycles Are Manufactured, Not Emergent

Cummins quotes Venkat Subramaniam: "I'm so thankful for AI. Finally, developers are no longer chanting microservices constantly." Anyone who has attended a few conferences recognizes the pattern — this year everything is AI, a couple of years ago everything was microservices. Her list of things that were each going to save everything: grid, Internet of Things, digital twin, model-driven development, low-code, Cloud Native, microservices, Kubernetes.

Her sharpest illustration of hype detached from engineering is the parent company of Cloud Foundry taking a large stock-market nosedive when investors noticed that Cloud Foundry did not contain Kubernetes — obvious to practitioners, a shock to investors, who sold because the buzzword of the moment was missing. Then comes what she calls the morning after the technology before, when we realize it did not solve everything and swing back. Amazon Prime Video's widely discussed blog post about moving from microservices to a monolith and saving 90% of costs is, in her reading, not evidence about monoliths versus microservices at all. It is evidence that the lunch was not free and that we were badly surprised by the price tag.

The structural explanation comes from Meredith Whittaker, president of Signal, who when asked which technology was most overhyped named none of them: it is not that one piece of technology is overhyped, it is that hype is a necessary ingredient of the current business ecosystem of the tech industry.

Cummins unpacks the mechanism. A company grows through funding rounds until it reaches an exit — typically an IPO or acquisition — at which point large amounts of cash arrive and the company becomes someone else's problem while the founders walk to the bank. In an ideal world, investment would be attracted by stability, profitability, good management, and reliable revenue. In practice it is attracted by growth and excitement, because an investor needs not only to feel excitement but to be confident that everyone else feels it too, so that follow-on rounds happen and the exit arrives. That requirement is what produces the hyperbole. Her examples: Anthropic's CEO saying AI would be writing 90% of code in three to six months — said a year before this talk — and Microsoft's AI chief saying all white-collar work would be automated within 18 months.

Architecture And Data Flow

The following diagram is my synthesis of the causal chain Cummins described in narrative form; she did not present it as a diagram, and it is a teaching aid rather than her architecture.

flowchart TD
    A["Investor needs a return
above the risk-free rate"] --> B["Growth and excitement
attract funding"]
    B --> C["Public hyperbole from
vendor leadership"]
    C --> D["Follow-on funding rounds"]
    D --> E["Exit: IPO or acquisition"]
    C --> F["Industry-wide adoption pressure
and conference monoculture"]
    F --> G["Technology under-delivers
against the promise"]
    G --> H["Swing back to the
previously dismissed idea"]
    H --> B
    I["Interest rates rise
(post-ZIRP)"] --> J["Bonds compete with
venture risk"]
    J --> K["Less investment,
less hiring"]
    L["AI-product vendors must
demonstrate their own product"] --> M["Layoffs framed as
AI productivity gains"]
    K --> M
    N["Overhiring during ZIRP"] --> M

The Promise of a World Without Developers

The current hype promises a world without developers, which Cummins points out is a very old promise. Low-code made exactly this claim. COBOL made it earlier still: it was advertised as English-language programming, on the theory that if not your manager writing code, then at least domain experts could write it and managers could read it. The outcome was the opposite of elimination — COBOL unlocked a whole new profession of application developers alongside systems developers.

That inversion is Jevons Paradox: efficiency improvements can lead to increased consumption. Her preferred illustration is road widening. The road you have to use is congested, they announce a widening, and you think: at last, the same amount of traffic will be running along this much wider road, it will be heaven. What you get instead is all the drivers who were previously put off deciding to take it, so your journey takes exactly as long, with more cars completing it. She predicts the same for software.

The contrast case is a profession that genuinely disappeared: the knocker-up, a human alarm clock who woke Industrial Revolution factory workers before alarm clocks existed — the profession survived into the 1940s, and into the 1970s in parts of England. It vanished because demand for it is fundamentally finite: only people with jobs outside the home need waking, and nobody wants to be woken six times because they enjoyed it. Software demand behaves in the opposite way. Cummins runs the escalation for laughs but the structure is serious: software to do things, then software to tell people about the software, then software to bypass the ads, then software to bypass the bypass so the ads still show because someone must be paid, then software to gamify it, monitor it, manage it, write it, debug the vibe-coded output of the software that writes it, manage the software that writes the software, avoid Skynet, and work out the meaning of life. Her historical claim is that every new layer of abstraction has increased the number of developers, not reduced it.

What the Job Numbers Actually Track

Cummins takes the obvious objection seriously: US developer vacancies dropped sharply, the UK looks somewhat better but still bleak, and layoffs are announced constantly with AI credited each time. She offers three deflationary explanations.

Vendors must eat their own product. If your product's promise is that it lets everyone else remove headcount, you have to remove your own headcount or nobody believes the promise.

AI washing. Companies without an AI product still face FOMO — everyone else claims extraordinary productivity gains, so you must appear to be getting them too or look badly run. Putting AI in a headline disguises news that is otherwise poor. Her example is Block, whose business she says was not doing well before its significant layoffs.

Overhiring, then rates. Overhiring is people-stockpiling, an accepted business practice partly driven by the same investment-attraction logic: hiring lots of people, needed or not, signals success. That works until the economic cycle turns. Here she introduces the ZIRP — a zero interest-rate period, which does not mean zero interest but rather below 1%. From roughly 2010, interest rates bumped along near 1% until rising sharply in the last three years. That rise was a shock to a lot of organisations, which had to change how they were being run because money was suddenly no longer free. She frames it as a return to normal rather than an anomaly: the fifteen-year cheap-money era is the outlier against a longer history of high rates.

The investor logic follows directly. Startup investment is high-risk with potentially high return; a government bond is low-risk. During a ZIRP the bond returns roughly 0%, which is a waste of capital, so money flows to software. Post-ZIRP the bond might return 4%, which starts to look attractive against software's risk, and capital is siphoned into safer instruments. Less investment means less hiring means fewer jobs. Her key data claim is the timing: the big peak in developer employment coincided with very low rates and the slump with rising rates, and ChatGPT's introduction barely registers on those job figures. She also presented more recent data showing developer vacancies rising again while the grey line for overall hiring stays low — so it is not simply general economic recovery.

A World Without Rest

The second broken promise is a world without work. Cummins puts it as a general rule: every time productivity increases, we are promised that the increase will eliminate work. Keynes is her instance — he predicted in 1930 that by the 21st century we would work a 15-hour week. What many people are experiencing instead is a world without rest — burnout, hustle, grind, 996 — and a further form of debt: sleep debt.

This too is a recurrence. In 1826 the average working week was 66 hours: six days, twelve hours each. Cummins shows a dataset of average UK working hours running from around 1300 to the present, and the striking thing is that 1826 was a peak, coinciding with the peak of the Industrial Revolution — enormous productivity gains accompanied by working more, not less. It took time to realize that working more was not helping as much as hoped. Henry Ford moved his factories from a six-day to a five-day week with productivity roughly unchanged. Her explanation is the default mode network, the part of the brain that becomes more active when we are doing nothing and helps us solve problems: doing nothing has real value.

So does AI give us more nothing? Her answer is no. She cites widely reported findings that professions using AI are working three hours more per week than they did before AI, and than other professions. The articles call it a paradox; she identifies it as Jevons Paradox again — capacity went up, the cost of doing things went down, so we do more things. The felt experience is a mix of euphoria at what the tools can do and fear from the layoff headlines, producing what she calls a productivity panic in which we go as fast as possible and produce enormous quantities of stuff. She borrows the phrase disposable busyware from one of those articles, because build-versus-buy has collapsed entirely towards build it, throw it away, build it again.

Her judgement is blunt: workslop is pollution, and we are polluting our digital environment with things we did not need and should have questioned before building. Code is not an asset, it is a liability — even good code — because more code means more technical debt. What the industry has agreed to is vibe now, pay later, and the pay-later part has started arriving. She cites the widely reported case of Amazon telling staff after several outages to ease off agents, adding that the version she heard was a week-long moratorium on agents plus a rule that junior and mid-level developers cannot ship agent-produced code without senior sign-off. She explicitly flags this as a rumour rather than a confirmed policy.

Engineering Discipline and Epistemic Debt

The counter-swing is already visible. Cummins notes Kevlin Henney's joke about wanting to write a talk called "I told you so", because small steps, committing as you go, and the rest of the disciplined practices are fashionable again. She is enthusiastic about TDD's return and openly ambivalent about the spec's return — her first role required a 500-page spec — while allowing that specs might be different this time.

The reason discipline is returning is epistemic debt, a term she credits to Simon Wardley: the collapse of competence, what happens when you ship code you do not understand. Naturally, this is an old argument too. Dijkstra said the use of COBOL cripples the mind and that teaching it should be considered a criminal offence, on the grounds that anyone who learned it could never become a proper engineer — aimed at exactly the same English-like readability that COBOL had been sold on. Cummins refuses to take the purist side. There is a lot of snobbery around this, and the honest position is that nobody understands all the low-level details: almost none of us are hardware engineers, very few of us write assembler, and we work at higher abstraction levels because we want to get things done. The trade-off between shipping and understanding the substrate is permanent; what changes is where the line sits.

The Unifying Model: Debt Is a Trade-off With the Future

Cummins closes by connecting the five debts she has walked through — ecological, financial, technical, epistemic, and sleep — with a single definition:

Debt is a trade-off with the future.

That definition is what makes idea circularity predictable. Ideas come back round when the trade-off shifts, and a trade-off shifts when the external environment changes. At the moment it tilts, the returning idea does not look like a trade-off at all — it looks like having your cake and eating it.

Her advice for getting better at seeing the repeating patterns starts as a joke — be old — which she then rejects as neither actionable nor true. Her counter-example is Greenspun's Tenth Rule ("any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp"), which is precisely a prediction of recurrence, and which Greenspun wrote at 29. Young and grumpy works as well as old and grumpy.

What she actually recommends is stepping back to the fundamental questions — what problem are we solving, and what is the trade-off — and being curious about both the past and the present. The high-value question is: why are things the way they are now, and have the assumptions changed? Changed assumptions are where the opportunity is. Her examples of live resets: analog computing, which can be more energy-efficient and performant than digital for some work; SQL, which did not die, with SQLite doing interesting things; Quarkus making Java's performance competitive with languages like Go; and GitHub capturing an enormous opportunity by moving back to a centralized model.

Trade-offs And Limitations

A trade-off that has tilted is still a trade-off. The central caveat of the whole talk is that when a recycled idea suddenly looks free, the cost has moved rather than vanished.

The evidence varies in strength. Cummins labels her sources as she goes: the Amazon agent moratorium is explicitly a rumour she heard, the Quarkus figures are her own team's experiments, and the three-extra-hours AI finding is something she describes as widely reported and has seen presented several times rather than something she independently verified.

The employment argument is correlational. Aligning the hiring peak with the ZIRP and the slump with rate rises is a strong pattern, and the ChatGPT non-blip is a genuinely useful observation, but rate movements and AI adoption are entangled with everything else in the macroeconomy. She does not claim a controlled result, and (my assessment, not hers) the pattern is consistent with her reading without excluding other drivers.

Epistemic debt has no clean threshold. Cummins offers no rule for how much of the substrate you must understand, only the observation that the answer is neither "all of it" nor "none of it" and that shipping code you do not understand has a cost that arrives later.

Not every returning practice is a good one. Her ambivalence about the returning spec, grounded in a 500-page document, is a reminder that "old idea comes back" is a description of a mechanism, not an endorsement of whatever is coming back.

Practical Takeaways

• Ask what assumption changed before adopting or rejecting an approach. The useful unit of analysis is not the technology but the environmental condition that set its trade-off — container immutability for Java dynamism, cloud economics for centralization, interest rates for headcount.
• Look through the graveyard of dismissed ideas for ones whose blocker has disappeared. Cummins frames this as the highest-leverage move available: recycling an idea everyone forgot, in a context where it now works.
• Refuse the free-lunch framing in architecture proposals. When a change appears to have no cost, find where the cost moved before committing.
• Read vendor and executive predictions through the funding mechanism. A claim that attracts a follow-on round is not evidence about engineering timelines; check whether the claimant's product requires the claim to be true.
• Treat AI-attributed layoffs as an empirical question. Check the company's prior financial position and hiring history before concluding anything about AI's effect on your own role.
• Budget carbon like any other non-functional requirement. Performance work and carbon reduction frequently move together, which gives efficiency work a second justification when the first one fails to persuade.
• Architect for shutdown, then shut things down. Make restart-safety a requirement so that turning off idle environments stops being a gamble.
• Ask "should we build this?" before "how fast can we build this?" Cummins' position is that cheap generation makes the prior question more important, not less, because unneeded output is pollution and every line is a future liability.
• Put a competence gate on generated code. The specific control she cites is senior review before agent-produced code ships; the general principle is that shipping code nobody on the team understands is borrowing against future incident response.
• Protect non-working time as an engineering input. The default-mode-network argument and the Ford five-day result are her case that idle time produces problem-solving rather than competing with it.
• Take the young-and-grumpy insight seriously. Pattern recognition across cycles is a learnable habit of asking about history, not a seniority privilege.

Key Terms

• Idea circularity — Cummins' framing for technical ideas that disappear and return, driven by shifts in the trade-off that originally killed them.
• Hype cycle — The pattern of an industry-wide surge of enthusiasm for a technology followed by disillusionment when it fails to solve everything. Used loosely here, as Cummins uses it, rather than as Gartner's named model.
• Jevons Paradox — The observation that efficiency improvements can increase total consumption rather than reduce it.
• ZIRP — Zero interest-rate period or phenomenon; in practice a period of interest rates below 1%, roughly 2010 until the last three years.
• Epistemic debt — Credited to Simon Wardley: the collapse of competence that results from shipping code you do not understand.
• Sleep debt — Cummins' addition to the debt family, describing the deficit accumulated by a culture of hustle, grind, and 996 working patterns.
• LightSwitchOps — The practice of turning computing resources off when they are not in use, requiring systems that tolerate being restarted.
• AI washing — Attaching AI to an announcement to reframe news that would otherwise reflect badly on the business.
• Disposable busyware — A phrase Cummins borrows approvingly for software produced quickly and discarded, without a durable purpose.
• Workslop — Low-value generated output. (Supplied gloss: Cummins uses the word without defining it, asserting only that "workslop is pollution, fundamentally" of the digital environment.)
• Default mode network — The brain network more active during rest, which contributes to problem-solving.
• Greenspun's Tenth Rule — The observation that any sufficiently complicated C or Fortran program contains an ad hoc, bug-ridden, slow implementation of half of Common Lisp; cited here as an early prediction of recurrence.
• Knocker-up — A pre-alarm-clock profession of human alarm clock, used as the contrast case of a job that technology genuinely eliminated because demand for it was finite.

Cummins' conclusion is deliberately modest. Nothing is new under the sun and there are no new ideas; there is almost always a trade-off, though occasionally there genuinely is not. Sustainability matters environmentally, matters for people working at a humane pace, and matters financially, because financial unsustainability eventually comes back to bite. And the practical instruction that follows is to go looking for the ideas everyone else has forgotten and recycle them, because in the current context they may turn out to be very good ideas indeed.

Reference: Holly Cummins, The Free-Lunch Guide to Idea Circularity, QCon London, published by InfoQ; page dated July 31, 2026.