Who Was Driving?

A public institution. A screen with code on it that was written thirteen years ago. Nobody in the building wrote it. The people who did have moved on, retired, scattered. The code still runs every night, and it moves numbers that end up in newspapers and budgets. The careful engineer showing it to me says the sentence I have heard, in some form, at almost every place I have ever consulted. “Nobody really knows why it still works. But it works. So we don’t touch it.”

Thirteen years. Hold that number.

And when they do have to touch it, here is how they make sure the change is right. They push it to development, and a person opens the screen and clicks through it by hand. Looks fine. They merge to staging, and a person clicks through it again by hand. Looks fine. They merge to production, and then they use it. With hope. That is the test. Three environments, three manual look-throughs, and a quiet prayer at the end. No assertion was ever written down. Nothing will ever check this again on its own. It worked on the day a tired person looked at it, and that day is the warranty.

Old-fashioned. Almost honest, in its way. Every check happens after the code already exists, performed by eyes that already know what the code is meant to do, and the last line of defense is the word hope. At least nobody here is pretending it is anything more.

Because the pretending happens somewhere else.

The companies that “have tests”

Move up the food chain. Leave the basement and walk into a larger, richer company, the kind with a wall of green checkmarks and a number near the top that says 84% coverage, the kind that would never deploy untested code, the kind that says, in the interview, that quality is part of the culture. They have tests. Thousands of them. They run on every commit. Nobody there would ever ship the way the basement ships.

When were the tests written?

After. Almost always after. The engineer wrote the function, got it working, watched it do the thing in the browser, and then, because the process required it, because the pull request would not merge without it, went back and wrote a test. And the test passed. Of course the test passed. It was written by a person who already knew exactly what the code did, looking right at it, shaping an assertion to fit the behavior already on the screen.

Ask it slowly. What did that test verify? That the code does what the code does, and nothing more? The engineer read the implementation, wrote down what the implementation already said, then ran it to confirm the implementation agreed with itself. Has anything been tested here? Or has the code simply been written twice, once in the language of doing and once in the language of checking, by the same hand, in the same hour, with the answer in plain view the whole time?

What do we call sitting an exam with the answer key open on the desk? And is that the word anyone reaches for when they want to say diligence?

The mirror

What is a test written after the code, if not a mirror? What can it show the code, except its own face?

Picture the simplest possible bug. A function that adds sales tax, and somebody typed a plus where a times belonged, so instead of multiplying the price by the rate it adds the rate, and on a ten euro item it returns ten euro and twenty-two cents instead of twelve twenty. Wrong. Quietly, expensively wrong, the kind of wrong that ships and bills a hundred thousand customers before anyone notices.

Now write the test after. You look at the function. You see it returns 10.22 for a ten euro item. You write the assertion: the total should be 10.22. Green. The test passes. The test will pass forever. And what is it guarding, this green and passing test? The day some honest engineer goes in to correct the math, the test turns red and screams, and the bug is what it screams to protect. So which did the test defend, the math or the mistake? Did you catch the error, or notarize it, and hand your worst mistake tenure?

That is what a mirror does. Whatever the implementation says, correct or catastrophic, the after-the-fact test reflects it back and stamps it confirmed. So when a company tells you it has 84% coverage, what has it actually told you? That 84% of the code has been written down twice. Has it said a single word about whether any of it is right? Can that number reach the question at all, no matter how green it goes?

And here is the part that should itch. The basement with its thirteen-year-old code and no automated tests at all, and the modern company with its wall of green, are they really doing different things? One sends a person to click through three environments and then hopes. The other writes a mirror that always agrees and then watches it go green. Both decide whether the code is right by looking at what the code already did. Neither one said, before the code existed, what right was supposed to mean. One of them just admits it.

The word in the middle

There is a name for the practice where the test comes first. You know it. Three letters, on every résumé, in every job post, claimed by nearly everyone. Test Driven Development.

Sit on the middle word. Driven.

What does it mean for something to drive? Does a driver not sit in front? Does a driver not choose the destination before the key turns, before the wheels move, before there is any road behind to look back on? Is the driver not, by the plain meaning of the word, ahead of the journey rather than behind it?

Now look again at the test written after the code. Was it driving? It showed up after the destination had already been reached. It read the map once the trip was over and announced, with great confidence, the route you had already taken. What does a thing that comes last get to call itself? Navigation, if it likes. But did it ever once touch the wheel?

So when a team says it practices Test Driven Development, and the tests come after the code, how much of that phrase has it earned? Development, certainly. Tests, yes, technically, there they are, green. But Driven? If the middle word is the entire claim, and it is the one part almost nobody performs, why does the badge stay on the résumé? Because the badge is what the audit wants to see? And the audit, like the test, mostly checks whether the code does what the code does.

But it still runs

And yet.

Thirteen years. Remember the number. That code, untested, undriven, written by people who are gone, still runs every night and moves the numbers of a country. Another company I have written about before ran for seven years without a single test ever written, and it did not die of that. It died for other reasons, the way companies do. For seven years its untested code shipped and worked and made a real thing that real people used and paid for.

So let me say the part the testing zealot would rather went unsaid. You can do this. You can write code with no test, ever, ship it, and have it run for thirteen years. It is allowed. It works. The basement is the proof.

What kind of trip is it, though?

It is a road trip with no destination. Not hitchhiking, exactly. You are driving, you have a car, your hands are on the wheel. You simply never decided where you were going. You turn left because the light is green, right because the road looks nice, you let the path be chosen by whatever happens to come up, by events, and you end up somewhere, and the somewhere is real, and you arrived, and you can live there for thirteen years. It is a way to travel. Some people will tell you it is the only honest way to travel, that naming the destination in advance is a small cowardice, that the best places are the ones you never meant to find.

I am not going to tell you they are wrong.

I am only going to ask what you call it. And whether the word on your résumé, the one with Driven sitting in the middle of it, describes the trip you actually took.

But what if you don’t know where you’re going?

Here is the strongest objection, and a good engineer will raise it before I have finished the sentence. Sometimes you genuinely do not know where you are going. Sometimes finding out is the entire point of the work. You are building a thing nobody has built, feeling in the dark for the shape of it, and writing the destination down first, as a failing test, assumes you already know the destination. And if you already knew it, would it still be the interesting kind of work?

There is a real case that the best software is discovered and not specified. You write the rough thing, you play with it, the playing teaches you what it was supposed to be, and only then does the real shape arrive. Demand the test first and perhaps you foreclose the discovery. Perhaps you nail the destination to the floor before you have learned enough to know it is the wrong one, and then you drive there beautifully, efficiently, fully tested, and arrive at a place you should never have gone.

I find that argument genuinely hard to answer. So I will not answer it. I will ask one thing back instead. On the day the road finally taught you what you were building, the day the shape came clear and you finally knew the destination, what did you do? Did you leave it as you found it, undefined, the target still a rumour even to you? Or did you, the moment you understood the thing, write down what it was supposed to do, so that the next change, or the next engineer, or the version of you six months from now could not quietly break it without something turning red? And if you did that… was the test ever the enemy of discovery? Or only the enemy of pretending the discovery was finished before it was?

The machine writes the test now

Here is where it stops being a question about you, and becomes a question about the thing on your desk that is writing code while you read this.

Two engineers, both using the model. Watch their hands, because from across the room you will not tell them apart, and the difference is the whole thing.

The first one, the one I would trust, opens with the test. Before the model writes a single line of implementation, this person has written, or made the model write under a hard eye, a test that says what correct means. A failing test. Red. A destination fixed in place before the journey begins. Then, and only then, the model is let loose to drive toward it, and the test rides in the front seat the entire way, refusing to go green until the code actually reaches the place the human chose. The model is fast and tireless and it does the driving. It does not get to choose where.

The second engineer just asks the model for the feature. The model writes the code. The code looks right. It runs. Ship it. And if a test is wanted later, for the pull request, for the coverage number, the model will gladly write that too. A lovely test, perfectly fitted to the code it just produced, green on the very first run. The machine has written the implementation and the mirror that confirms the implementation, both, in one breath, and handed you a wall of green that means precisely nothing, because the same mind wrote the answer and the answer key, and that mind was never trying to find out whether it was right. It was trying to agree with itself. It is extraordinarily good at agreeing with itself.

And notice who is who. We would all like to believe the careful one is the senior and the careless one is the beginner. Is that what you see? Or is the real gap between the people who decided what correct meant before they asked, and the people who let the most confident voice in the room define correct for them after the fact, whatever their years?

What is sitting on your desk, if not the most fluent thing ever built? Ask it anything and it will produce an explanation, a justification, a confident paragraph defending code it wrote three seconds ago. Where, in all that fluency, is the commitment underneath the talk? And what has ever stopped a talker like that? Not the better argument, surely, since the talker always has another one ready. What stops it is a question with a fixed answer, the one thing it cannot charm its way around. Is a failing test not precisely that? Red until the code does the real thing, and what speech has ever talked red into green?

Take the test away, and what have you removed? Only the single move in the whole exchange the machine cannot win by talking. And what is left then, except the most persuasive thing ever created, writing the code and the proof of its own correctness in one gesture, while a human nods along, presses ok, and watches the mirror go green? The people who have given their lives to this craft keep repeating one warning now that the code has gotten cheap: that AI is real, that it changes everything, on a single condition. That it runs inside a harness it cannot argue its way out of. Why would they all reach for that exact word? What do you put a harness on, if not a thing that is strong, and fast, and does not get to choose the direction?

When the machine writes the code, and the machine writes the test that proves the code, who tested whom? And which of the two did you actually trust?

So who was driving?

Go back to the basement. Thirteen years, still running, no test, no destination ever named. By the one measure of survival, it won. It is still alive. It has outlived companies that kept a wall of green, because survival was never the thing the test was for.

That is what the green wall and the basement both miss, from opposite ends of the same mistake. If all you ever wanted was for the code to run, you already have it, and you never needed a test to get there. The basement is the proof, standing in front of you. So was the test ever about whether the code runs? The code runs. Was it about whether you knew, before you built it, what it was supposed to do? Whether you chose the destination, or let the road choose for you and then wrote down the route afterward to feel like a navigator?

You have tests. Good. That was never the question. Almost everyone has tests, or coverage, or a green wall, or at least a staging environment and a person who clicks through it and hopes. The question underneath all of it, the one the middle word of the acronym has been asking the entire time:

Was anything driving?

Or did you arrive somewhere real, somewhere that works, somewhere you could live for thirteen years, and only then turn around, look at the road unspooling behind you, and write down where you had been going all along?

And if the test came last… when, exactly, did you decide where you were going?