Every thriller has the scene. A person in a hood sits down at a keyboard, green text scrolls, and someone says "I'm in". I have spent thirty years building the systems that scene pretends to break, and I finally got tired enough to try the alternative.
Film has to compress, and with most compression comes loss. We can still enjoy it. But this scene is misleading about where the danger is, and the reality is scarier. So I started thinking: could I make a lossless compression of software development for fictional entertainment?
Where the danger actually is
Fiction shows compromise as fast and solitary. Real compromise is slow and social. It looks like a contractor with a plausible name and a clean commit history. The change goes through on a Friday afternoon because the reviewer trusts the author, and trusting the author is what makes software teams work at all.
The sentence that should frighten you is "the tests passed and it merged".
There is fiction that gets the technology right. Stephenson did. Suarez did. What I had not seen was fiction that gets the development process right: the review queue, the release pipeline, the way a change becomes something thousands of machines run because a build server signed it. That process is where I have lived since the nineties, and as a thriller setting it has been sitting unused. Every safeguard in it is social, and anything social can be leaned on.
So that was the bet. Write a thriller where the technology is correct and the process of building technology carries the story. The villain does no breaking in. He gets his change approved.
The crime fits in a code review
The book is called The Chain. A developer builds a blockchain platform, the money behind it turns out to belong to people you cannot resign from, and the crime at the center is small enough to pass through a code review without anyone flinching.
I will not say more than that, because the mechanism is the mystery and some of my readers can read code. It is a compiler person's crime. It lives in the gap between what a tool verifies and what a human believes the tool verifies, and anyone who has shipped a validator knows that gap is real. Nothing in it required invention. The pieces are boring and checkable, and boring, checkable pieces are what real disasters are made of.
The rule I set myself was that a working engineer should be able to read any technical page without flinching. Keys are stolen instead of broken, and the climax is a consensus upgrade, so the last action scene is convincing people who do not trust you.
What correctness costs
The hard part turned out to be cutting technology that was correct and earned nothing.
An early draft explained elliptic curve parameters at a garden party. The appendix contained a worked example that I removed because it gave away the ending to anyone who could read it.
Accuracy that bores a reader is a craft failure, so the compression takes its loss here: detail goes, the shape of the danger stays.
The test
The claim "the technology is correct" is empty while the author is grading it, so the manuscript went to working engineers, people who have run production systems and written the post-mortems afterwards.
Thomas Arts, who built the property-based testing tools much of the Erlang world runs on, read it and said the technology connects to what he knows, down to the property-based testing one of the characters insists on.
A different beta reader, one who does not program, told me the opening chapter made him feel the protagonist's anxiety before he could say why.
The book
The Chain comes out on 9 September. It is published under the pen name Frank Able, which as of this week is publicly what it always quietly was: me. The first chapter is free at readthechain.com, the Kindle edition is on Amazon for pre-order, and there is a soundtrack, one song per chapter.
If you build systems for a living, I tried to write this so you would not flinch. Tell me where I failed. That is a bug report, and I answer those.
