Can principles of fiction writing improve your code?
I recently attended a writer’s conference at Wesleyan University, my alma mater, which touched off a series of thoughts about writing software.
One of the common questions at the conference was, “So, what kind of writing do you do?” When I answered that I wrote software, the reaction was interesting. I got either puzzlement (how is that writing?) or sage understanding. To assuage the first group I started answering that I hoped I was writing non-fiction.
Code As Dialog
The workshop that stuck with me the most was a discussion about writing dialog. The author leading the workshop asked the class why some dialog didn’t work. He gave as an example the dialog from a Honda advertisement.
Person1: I just bought a new Honda.
Person2: Wow, is that the one with great gas mileage and a 5 star government crash test rating?
Hands, please. How many feel that this bit of dialog works?
Right. Neither do I. Neither did the workshop leader. But the interesting question is, “Why doesn’t it work?”
The workshop leader’s explanation was that this dialog didn’t work because the participant was lying—his character simply wouldn’t normally talk that way.
Dialog that isn’t true to the characters won’t work.
I’ve always been a big fan of the notion that creativity comes from taking ideas from one domain and seeing what happens when you put them into another domain. So I decided to think of my code as dialog and see how well this rule about dialog applies to code.
Think of your classes as the actors in a drama. Is your dialog believable? Would that class really say that? If your class is making a “special” call to another unrelated class, perhaps it isn’t just a case of bad coupling—perhaps your class is lying!
The mandate to “decrease coupling and increase cohesion” has been around for so long that it seems to have lost its meaning. I know lots of people who can quote it but then admit they have no idea what it really means. Perhaps thinking about your classes as actors in a drama can make it more real.
Think of the movie Tron (the original or the recent sequel). Many of the characters in that movie were computer programs. I remember that in the original, one of the programs was an accounting program. When he introduced himself to the title character, Tron, he said something like, “I’m an accounting program. You know, it feels good to know I’m helping improve people’s financial health.” The line was striking because it was totally in character: it was just what you’d expect an accounting program to say if it talked to you!
What would your programs say if Tron ran into them? “Hi, I’m a side-effect manager; I’m supposed to do thread scheduling but sometimes I randomly update the printer queue.” Poor Tron would tilt his head and say “huh?” He’d be dealing with an inconsistent character, one not true to itself.
Taking this analogy a step further, let’s talk about the Show Bible.
The Show Bible
At the same writer’s conference I attended a talk about writing for a TV series. Many such series accept third-party scripts. The challenge for the freelancer pitching a story to an established series is that the series is a little world with all kinds of rules about how the characters act and speak.
To give the freelancer a better chance of writing something that will work, one of the things they give you before you create a story for them is the Show Bible. This document describes the universe of the show: “Monk can touch money but needs a wipe after shaking hands,” “Star Fleet officers don’t need money but normal people in the Federation do,” “Spike (on Buffy) can drive a car in the daylight even though he is a vampire.”
So can the idea of the Show Bible be applied to software development projects? I think it can; in fact, I think the Show Bible is very much like a project architecture document—or perhaps a group’s Design Philosophy guide. It spells out the rules for the universe of the creation, what’s acceptable and what’s not. You can certainly violate the rules on occasion, but to the degree that you don’t, your story will be better—whether it’s the story you’re pitching to the TV series or the story your code is telling.
We spend our time worrying that our code is doing the right thing rather than trying to make it elegant or beautiful, as if the two concerns were unrelated. Perhaps if we tried to write better stories we'd end up with fewer bugs.
Brian Tarbox is a Distinguished Member of Technical Staff at Motorola where he designs server-side solutions in the Video On Demand space. He writes a blog on the intersection of software design, cognition, and Tai Chi at briantarbox.blogspot.com.