Imagine with me: what if novels were written like software.
Sometimes it’s useful to approach absurdity and look inside. There might be treasure there.
I’ll define software as an executable, a set of instructions, that are interpreted by a machine for some reason. As a data scientist, I think of software as a product, and I think, constantly, of turning data into product. I think of data as inertia and all the code around it as flexible. I worry a lot about the people that use the software (if anybody) and think of them as heterogenous segments.
I think of a novel as an executable, a set of instructions, that are interpreted by a human brain for some reason. As a data scientist, I think of a novel as a product, and I think, constantly, of turning word salad into vectors and into the merchandizing/movie rights. I think of the dramatic structure as inertia, and all the ideas around it as flexible. I worry a lot about the the people that use the novel (if anybody) and think of them as heterogenous segments.
For Some Reason
Software exists for some reason. As does a novel. And they can be executed in different ways. People hire software to do something for them. People hire a novel to do something for them.
Because people have different reasons for hiring things, I like to segment people by those reasons. Sometimes you hire a novel because you want to get a good grade. Or to fit in with your friends. Or to boil time. Or to escape. It’s aways for some reason. Very few people sit down and consumes a linear executable without a reason.
People hire software to do a lot of different things too.
Software may express itself in multiple executables.The conversational interface like Alexa or Google Home. Tortured in a web browser. The IOS app. The android app. The screen at the airport. The Mac. The Windows. A VM running linux. Lots of code and configurations are cajoled into orchestrating a coherent experience.
Novels may too. The novel typically comes to us in a linear format – a sequence of tens of thousands of words, arranged linearly (with the exception of the Choose Your Own Adventure Series), and structured into chapters. Sometimes the novel is read out loud and it can be consumed through the ears, but still in a linear way. Sometimes the novel itself is translated into movie form. Sometimes it’s the inverse.
Software tends to be interactive. It isn’t necessarily a linear experience. But it can be. And interactivity tends to fall along some spectrum.
The act of creating something is creation. And most people interviewed for this post agreed that a novel is created. There’s some consensus, among a narrow peer band in Toronto during the late teenties, that creatives create creative. And we think of the people who construct a novel as generally being creative.
It’s curious that we call the people who create software different things. I used to hear the word resources too much. No longer. They’re people. The developer. The architect. The information architect. The product manager. The data scientist. The developer. The business analyst. The project manager. The stakeholder. The product owner. The scrumaster. The engineer. And they don’t create software. They build software or build a product or write code.
A few people help build a novel too. The copyeditor. The ghostwriter. The editor. The illustrator. The typesetter. The publicist. The writer.
It takes a team to deliver a novel.
Yet, one writes a novel. The authors name appears on the cover.
It takes a team to deliver software. A team builds software.
There are a bunch of ways that one writes a novel.
The way it’s commonly told is that somebody has a vision. They pre-write something out. Then they refine it. Then they send it into a slush pile at a few publishers. Then it gets rejected. And then they’re done. The end.
Sometimes, something does get out of the slush pile, and the editor directs the writer into producing something sellable.
Another way is that an editor looks for something to fill out their catalogue, and commissions a novel with a set of specs. A veteran author pounds it out to spec. It’s then QA’d and then deployed to production. Pulpy.
And then I imagine there are a few authors that have established markets because of the reliability of their product line and they release whenever they want to.
One author told me that first they sketched out the characters, then their story, and then pre-wrote it out. Then, they’d pass over it a second time, filling in pieces. And then they’d give the whole thing another pass. Then it would go to the editor for notes. Then refinement. Then it would go to production.
When both the problem and the solution are both known with certainty to the publisher and the author, the way to execute is waterfall. There was a known market for war themed hard science fiction among second world war veterans. They wrote a novel for that market.
It’s similar to how the movie of the same name emerged in 1997. TriStar needed a sci-fi bug movie to appeal to the male 18-35 market segment. Verhoeven was good at delivering for that quadrant. He delivered an executable. That executable didn’t exactly mirror the novel.
When there’s certainty about product-solution-market fit, creative creatives create waterfalls.
The film Starship Troopers (1997) failed with the audience because the protagonist, Johnny Rico, became a fascist. His friend became a fascist. The love interest became a fascist. Were these the good guys? The general message, repeated by Verhoeven himself in commentary, that fascism is bad, that war makes fascists, didn’t find as much traction in the 1997.
The bugs looked great. The special effects were fantastic. The story arc was memorable. There a solid amount of violence and gore. And there even visible cues that were fun too, as an entire generation received a solid inoculation against the false enablement of ‘would you like to know more?’.
From a commercial perspective, there was core defect in the story, which limited its appeal. Johnny was supposed to be a hero. He was until he wasn’t.
There was waste here.
121MM gross on a 105MM budget.
Most novels fail.
Most software fails.
It’s terribly wasteful. There’s got to be a better way.
When the problem is known, but the solution isn’t, one uses agile (Broza, click here for more).
In software this manifests itself in all sorts of ways. Significant effort is typically deployed against figuring out market-problem-solution fit. Assumptions are surfaced and tested. Problems are interrogated until they yield their secrets. Work In Progress is minimized. Learning is accelerated because the best way to destroy risk and waste is through learning.
All the rituals that derive from this core stance – SCRUM, KANBAN, the 3M sticky, the standup, the retrospective, the point cards, estimation, and testing – they all derive from this core paradigm.
Most people who are certain about the problem and certain about the solution may view agile as a way of executing their vision, faster. When one has absolute clairvoyance, and certainty, that a course of action is correct, that person isn’t in a receptive state to learning. The root of agile is in continuous improvement and reduction of risk on the whole solution. Agile is ill suited to perform in environments of dead reckoning.
Does agile work? I’ve yet to see a very solid quantitative study on the subject. It may get caught up in that classic meme – “does fascism/communism/libertarianism work?” – “we don’t know because we really haven’t tried it properly yet”. Directionally, agile is good at preventing collapse and reducing software failure. It’s good when the solution isn’t known. It’s really bad when the product owner isn’t onboard.
Crunchbase remains polluted with failed startups that allegedly tried agile. (It’s very hard to tell if agile was really used, or if it was a proxy for waterfall).
We probably aren’t even aware of all the failed novels.
What would an agile approach to novel writing look like?
Hugh Howey offers a glimpse. Hugh started off the Silo Series with a short story, and sold it on Amazon. When he got market interest, he wrote and released parts of Wool. Then Shift. And when it looked like a studio was interested in the rights, he wrote a very cinematic climax in Dust.
Hugh didn’t know if there was a market for trilogy when he started. He built out the product as evidence accumulated from the market. He learned from the market. And then executed the rest of the story, minimizing waste, through to the end.
Did Hugh use KANBAN or SCRUM? Did he do a daily standup with himself? Did he assign himself JIRA tickets? Probably not.
I can still call it some version of agile because he minimized work in progress, he built only the amount of product required to learn, and he minimized risk and waste.
The Absurdity of Group Novel Writing
Alright, we’re going to build a novel.
We got a tight deadline here. If it takes one writer 90 days to pound out enough words, let’s hire three and do it 45 days, or so the logic goes. Let’s hire a story architect, a character designer, a release engineer, make sure we get a QA, and a product manager.
That’s eight people. Does it pass the Bezos test? Let’s order a pizza and find out? It does. We are ideologically consistent. Done.
There are eight, 45 day units, in a year. There are 8 people on the team. It’s roughly a person-year worth of effort involved in building this product.
In setting up the team, the product manager would ask:
“What problem are we solving with this novel?”
And the product owner, the publisher, might respond:
“We are investing $120,000 into this team. We’ll invest $120,000 in marketing so we’re looking for gross revenue of around $1,000,000. Make it pop. And keep it on brand. All digital sales. Look, I’m really not into this agile thing but the board is my ass about it, so I don’t care what it’s about.”
And that’s likely all the help the product manager is going to get. If they’re lucky.
The product managers internal dialogue might run along the lines that commercially, at 14.99, that’s around 66,666 digital copies gross, and a brutal CAC of a buck and change. So, it’s going to have to be a targeted book at some market segment that refers to itself when making a purchase decision. The product manager would take this as an optimization objective.
Their problem becomes – what customer problem does the novel solve – and are there enough people that this thing would solve for? The product manager doesn’t know. They need to use the collective wisdom of the team to figure out the mystery. The constraint is 6 weeks, which is roughly 30 business days (ex-vacation). There’s no time to lose.
The product manager attempts an ORID on the first day. They get everybody into a room for the kickoff. Alright folks, here’s the objective. How do we feel about the objective?
And it goes the way eight strangers might say it goes. Two of the writers are very angry that they have to work in this way. They’re artists dammit. One of the writers is quite amused. The story architect attempts to dominate the room with a massive rant about the importance of story. The character designer expresses concern that internal monologues aren’t emphasized as often, and that characters are the engine room of the story. The QA is worried about keeping track of how the book is evolving.
Alright, wide open field. Let’s talk about ideas for how we can meet this objective. On your 3M sticky, take ten minutes to write out all the ways we can meet this objective.
Somebody, helpfully, suggests that maybe the AI can do it.
And after the group has a good laugh, the product manager attempts to cluster the models and the ideas into columns.
There’s a mess of themes: Vampires, Zombies, Steampunk, Dystopia, Aliens.
There’s a mess of segments: Tweens, Elites, Kindle Readers, Mystery Readers, People who have a long flight ahead of them.
There’s a mess of structures: Drama, Tragedy, Comedy, Romance, You-Need-Go-Search-Find-Take-Return-Change.
There’s a mess of tools: Pages, Google Doc, Word, Excel, Storyboards, Cue Cards, Pitch Bible, Bitbucket.
Once they’re all up there, lists of lists of lists, comes the hardest part. It comes down to integration.
One writer is very adamant that the only solution to the problem is to write a novel about zombies, for tweens, romantic, and it must be in a google doc.
The story architect says that it must be a drama. Life is drama.
Another writer is very specific that the Google Doc must, absolutely, have versioning turned on.
This goes on until a bio break.
A product manager, at this point, in an effort to integrate around the objective, and may ask the group who they’re writing for, and why they’d read it.
And it’s perhaps at this point, somebody looks at which ebooks are getting purchased. Maybe somebody checks out google trends. Maybe a few ideas start to roil and a few models of what could be true start to emerge out of the mass of lists.
Maybe, for veterans of the 2001-20xx war, our novel, “Future Soldier”, is a story about a soldier that crossed the wrong people and gets himself into some serious trouble.
Maybe, for veterans, our novel, “Gordz”, is a story about two retired warlords who play chess at the retirement home and find peace in themselves after warring with each other.
Maybe, for veterans, our novel, “Future War”, is a story about a solider travelling future in time, and confronting the feelings of dislocation into the future.
Again, nobody knows for sure whether or not there’s a market for any of those stories. The solution to the problem isn’t known.
In an effort to get more data, perhaps the three writers produce three short stories, have them QA’d, and get the introduction of their idea up and published to production by the weekend? Maybe data could be gathered from the engagement with the stories? Maybe a few veterans could be interviewed?
In the meantime, the story architect may chart out the framework that each novel might have to take, and the character designer may ask people of the various demo targets questions about characters and features.
Data would come back from the field and decisions could be made to select a model.
From the selected pitch, the story architect is restricted to very few design patterns. Fundamentally, in a drama, the situation just gets worse and worse for the hero. And there are only so many story-telling modes in a novel which gel together to form a cohesive story.
The character designer, if such a role were to exist, would have to produce a bible that contains the attributes, behaviours, thoughts, feelings and probable responses to events, as well as work closely with the story architect to understand the key redeeming feature of the character that would clinch it at the moment of hopelessness. The character designer would probably always be at war with the story architect. To manage it, the product manager could always run a weekly test to check if the mix of story and character are working together. Maybe the character designer is absolutely insistent that Johnny doesn’t turn into a fascist.
The writers would have to fill in the details with words and agreed upon style guide. A writer might select a JIRA ticket for the description of the retirement home. Another writer might select a ticket describing the action between the warlords as they fight over the last of the coffee.
Something could be put together, with notes and samples shared with marketing and production as data comes in from the field.
Maybe a novel could be produced in such a tight timeframe? Maybe it could be good? One would have to run the experiment many times to find out.
The proof is non-trivial and left to the reader.
We ask groups of developers, designers, artists, product managers, marketers, data scientists and quality assurance engineers to work together to accelerate learning all the time to build software, often without total awareness of what is happening in all parts of the product.
A novel has a lot of features and is expressed in code that is compiled by a human brain and run through their hardware.
Software has a lot of features and is expressed in code, that is compiled by a machine, expressed through hardware, and then experienced by a human brain, and run through their hardware.
It’s absurd to think of the application of agile to novel writing because the author has a vision, and they have all the core skills to execute on that vision. So they do. The certainty of the author, or, the certainty offered to the author by the publisher, make for a very linear, waterfall, process.
Novels are episodic. Even in a series of novels, each one is capable of standing relatively alone. Once a novel is delivered, there isn’t much iteration on it. It’s gone to print. There may be editions of the novel and run of it. Generally, the novel is static.
Software tends to be continuous. Gone are the days of the CD-ROM. Today are the days of the Internet and continuous updates. Software is updated and evolved continuously. In systems where improvements are unknown, and the barrier to entry from competitors are fairly low, the ability to learn and improve is a differentiator. Morale is a differentiator.
The result are two different stances towards learning.
If Novels Were Written Like Software
We could make a few predictions – if novels were to be written like software.
For one, some people that are used to working alone in their silos would likely have a harder time working in a team. There are precedences for writers working in collaborative environments, that isn’t always the case when it comes to novelists.
For two, the first novel likely wouldn’t turn out great. In part because the team hasn’t learned out how to work together, and in part, because they haven’t learned a lot about a chosen market segment.
For three, the eighth novel would likely turn out great. In part because the team would learn how to work together and would have a learned a lot about a given problem-solution fit.
For four, more writers would learn to become great. A writer could go from writing scenes to becoming an amazing story architect in a few years. Their learning would be accelerated just by virtue of doing so much and getting feedback.
I’d predict that the dead reckoning will continue. Creative creatives create waterfalls. I think there’s something about being certain about something and following through on a vision. And unless you’ve tasted the bitter ash of being so certain, and being so wrong, and fessed up to it, maybe it’s just hard to theoretically accept learning. We’re living in the age of the indie writer after all. Artists should try. And will continue to try.
For five, talented people would continue to matter.
The whole thing is absurd of course, but maybe there are a few clues about how software teams work and the nature of creative industries.