Whose Battle Was It?

The brief was to validate an idea before it turned into a budget. The client had something they wanted to build, they wanted an outside architect to look at it and say whether it held together, and they wanted that before anyone wrote code. Reasonable. That is one of the better reasons to hire somebody.

The idea was small. Data came in from a handful of sources, a set of rules ran over it, the result went behind a screen and an API. Nothing irreversible happened anywhere in it. No money moved. On an optimistic launch day it would serve a few hundred people, most of them inside the same three hours of the morning. The rules were the only part that needed real thought. The rest was plumbing of the sort that has been written ten thousand times and works the same way in every language anyone would sensibly pick.

A few hundred lines of Go would have done it. That is not a boast and it was not meant as a provocation, it was just the estimate, and it was not a hard estimate to make.

The document said Java, on Quarkus, deployed to OpenShift.

The overhead there was not a rounding error to be tidied up later. The platform underneath the application was going to cost more to stand up, more to run, and more to keep somebody available for than the application itself, and not by a little. Someone asked why. Not aggressively. The way you ask when you assume there is a short answer and you simply have not heard it yet.

Because it’s battle-tested.

That was it. That was the whole answer and it was accepted. Nobody asked which battle. Nobody asked who had fought it, against what, on what hardware, under what load, in what year. The phrase went down on the table, the question closed behind it, and the meeting moved on to how long the sprints were going to be.

What is the word actually saying?

Battle-tested is in the passive. Something was done to the thing. It was taken somewhere, and it came back.

Put it next to plain tested. That word has a person inside it. Somebody wrote a test, picked the inputs, decided in advance what passing would mean, and all of it can be read afterwards by anyone who wants to. If the answer turns out to be thin, can you see that it is thin?

With the tester gone, there is no method to inspect, no criteria, nothing written down anywhere. What is left is a survival, described by whoever happens to be telling you about it.

So the claim is narrow. Reality came at this thing, and the thing did not die. Who was standing there while it happened?

Does that tell you why it did not die? Or which parts of it were even in the room when it did not? And the person saying so, could they take you through any of it?

Which war, though?

Java has earned the phrase, and that needs saying properly rather than as a setup for knocking it down.

It shipped in 1995. The applets it was marketed on are gone. Sun Microsystems, the company that built it, was bought by Oracle in 2010 and no longer exists. Android took the APIs, and the argument over whether that was allowed ran for a decade and finished at the Supreme Court in 2021. Every few years, for thirty years, somebody has announced the language that would finally make it unnecessary. Java kept shipping. Six-month release cadence since 2017, a long-term support release every couple of years, and it is still sitting underneath payroll, insurance claims, telephone billing, clearing and settlement, and a lot of the machinery that moves money between banks while everyone is asleep.

Those wars were specific. Forty-person teams with constant turnover. Code outliving the people who wrote it by a decade or two. Auditors, regulators, maintenance horizons measured in decades, thousands of concurrent users, and the expectation that something compiled in 2004 still runs, which is close enough to true that serious organisations plan around it. Java won those, and it won them decisively. Who would want to argue with any of that?

The properties that won them are just as specific. Near-religious conservatism about breaking changes. Tooling and observability that nothing else really matches. A hiring pool deep enough that whoever maintains it after you is already out there and employable. And a runtime that profiles itself as it works and recompiles the paths that run hottest, so the process gets faster the longer it stays up.

That last one assumes a process that stays up for months.

And what is a first version up against?

A first version has one enemy, and it has nothing to do with load or auditors. It is the chance that nobody wants the thing at all.

Everything else on the risk register sits downstream of that. All of it assumes the product is still there in a year. What is being tested here, if not that assumption?

It is a strange sort of fight, too. Finding out quickly that the answer is no counts as a win, and counts as a bigger win the less the finding out cost.

A first version wants to be cheap enough to be wrong. Battle-tested means expensive enough to be right. So which of the two was that stack sized for?

And of the money on that engagement, how much was going to the rules, the part nobody else could have built, and how much to a platform provisioned for a war the product had not yet reached? Which half would the client have defended in front of their own board? Which half did anybody in that room describe as the risk?

What was Quarkus doing in there?

Quarkus deserves its own paragraph, because it is the genuinely interesting thing in that stack and it went past unexamined.

Red Hat announced it in 2019 and it is good work. It exists to make Java start fast and hold less memory in a container, by moving into the build a lot of what the JVM normally does at startup, and, if you ask it to, by compiling ahead of time through GraalVM down to a native binary. The marketing calls it supersonic and subatomic, which is silly, but the engineering underneath is not silly at all.

It is built for Java’s startup cost. Java’s memory footprint. In a container. Why would a vendor that size fund years of work on a problem that was not real?

So the stack picked to show that Java’s overhead was nothing to worry about had inside it the framework a major vendor built because Java’s overhead was something to worry about. How did both of those get through the door under one word, in one sentence, with nobody having to pull them apart?

There is one more thing in that box. Red Hat builds Quarkus, and Red Hat sells OpenShift. Which raises something more general than that room. When a house stack is already licensed and already paid for, how often does the technical argument get made before the decision? How often afterwards, by people whose job is now to explain it? And from inside the room, would anyone be able to tell those two apart?

How do you read something wrong for forty years?

In 1900 Arthur Evans started digging at Knossos and came up with thousands of clay tablets covered in a script nobody could read. Linear B.

Evans decided the language was not Greek. His reasoning was not really linguistic. The Minoan civilization he had found was older and, to his eye, finer than anything on the Greek mainland, so its records could not possibly be in the language of the people who turned up afterwards. He held that until he died in 1941, and because he was Evans, everybody else held it too. How long does a reading stay alive on the authority of the man who found the tablets?

Alice Kober did the work that mattered. She counted. Sign frequencies, tabulated on index cards she cut out of library slips because there was a war on and paper was short. She found sets of words that changed their endings in regular patterns, which proved the language was inflected, and she would not go one step further than that. She never claimed to know which language it was, because the evidence did not say so. She died in 1950, at forty-three, before any of it turned into a decipherment.

Michael Ventris was an architect by trade. He had been interested in the tablets since he was a schoolboy, and for about a decade he argued that the language was related to Etruscan. He kept finding support for it, too, and that is the part that matters here. The corpus was small, the fit was judged sign by sign, and a reading that is partly right will throw off matches faster than it throws off contradictions. The tablets that refused to cooperate were set aside as damaged, or as a scribe’s mistake, or as some dialect nobody had accounted for yet.

So what would a contradiction have had to look like, to get counted as one?

In 1951 he worked through the Greek hypothesis as a side exercise he expected to end in nothing. It did not end in nothing. The following year he announced that Linear B was Greek, which meant publicly dropping the reading he had argued for since he was a teenager.

He had been collecting confirmations for the whole decade.

Where does this break?

Here, and it does not get patched up.

The small-corpus mechanism does not apply to Java at all. Java’s corpus is enormous and extremely well read. There are people who will tell you what the JIT does to a given loop after ten thousand iterations, what each collector does to your tail latencies, and which release changed that behaviour. The JVM is one of the most examined pieces of software ever written. Anyone wanting to argue that nobody understands Java would need completely different evidence, and this piece does not have any. So if the word was not wrong about Java, what was it wrong about?

The small corpus in that room was not Java’s. It was theirs. One product, one belief about it, nothing yet able to contradict it. What, in a stack sized like that, was ever going to arrive cheaply enough to count against them?

That is a smaller claim than the analogy seemed to be offering, and it should be said out loud rather than glossed. A scholar with a wrong reading is wrong, and sooner or later the tablets say so. A company that believes in its own idea might simply be right, and nothing available inside that meeting can tell you which one you are in. The decipherment does not settle it. Borrowing its confidence would be a con.

What would the few hundred lines have told them?

They would have been in front of an actual person inside two weeks, and they would have answered the one question that was live. Does anyone want this. They would have cost little enough that a no was survivable, and they would have left the budget intact for the second version, the one built after the rules turn out to be the wrong rules, which is what normally happens and is the whole reason for building something small first. What would those two weeks have cost, against what the platform was going to cost every month it stayed up?

The stack that got chosen answered something else. Something nobody in that room had asked, about a war that product had not yet reached. Who was that answer for?

So the next time the word lands on the table and the conversation closes behind it, ask them to name one. Not the industry, not the general sense that banks somewhere are running it. One battle. Who was on the other side, what year, what load it was carrying, the night it nearly went over and did not, and why it did not. And if nobody present can produce one, what was being cited?

If a system was tested by a battle, somebody was in that battle. Somebody came back from it. Did anybody write down what happened? Is that person still in the building?

Your system survived a war that finished before you got there. What battle is it in this morning, and who could still tell you?