Have you ever noticed that sometimes it’s easier to learn about the thing that’s right under your nose if you try to learn something new?
I remember learning French in ninth grade, and suddenly realizing that there was a structure to language that was different in different languages. All that nonsense about outlining sentences that we did in English class suddenly made a lot more sense to me. Of course, English is screwed up enough that it’s nice to have comparatively structured languages like French to help make sense of things. Except for adjectives. The French have screwy adjectives. Adjectives screwy? You put the adjective before the noun with some kinds of adjectives, or after the noun with others, or on either side depending on if you’re being figurative or literal — “un grand homme” versus “un homme grand”. You see?
Anyway, I’ve been learning more about writing lately, about all sorts of things. A couple of weeks ago I thought it would be funny to exclaim “fucking gerunds!”, but realized that nobody around would get the pun — they’d probably just edge away from me nervously. But bad puns aren’t the only thing I’ve been thinking of lately — another is that what makes great fiction and what makes great software are very similar.
The email list for my critique group had some discussion about “premise” lately, which was really interesting. We read a blog entry by Alexandra Sokoloff about answering the question “what’s your book about?”, and an article by Christopher Lockhart about constructing a logline (a premise in Hollywood-ese). Since then I’ve been reading Donald Maass’s “Writing the Breakout Novel”, and came across his section on premise.
Maass’s Premise list — what he looks for in a breakout novel — is:
- plausibility
- inherent conflict
- originality
- gut emotional appeal
I’d already been thinking about the way novels are created compared to the way software is created. This sounded very similar to my theory about the necessary ingredients in creating killer software:
- plausibility (can be done by the current development team in a reasonable amount of time)
- solves a real problem (for people who can pay you real money)
- originality (why is your solution better?)
- people want it (and they want it bad)
Let’s call that the promise — the software you commit to deliver. If you ask a writer “what’s your book about?” and they say “it’s a bit complicated to explain,” you probably aren’t going to see it on the shelf anytime real soon.
The same thing is true of software. If you ask the team “what’s in this next release?” and they say “Oh, a bunch of stuff,” you might not have that big sales uptick you’ve been hoping for.
But if they say “We’re coming out with features X, Y, and Z, which will solve huge problems for customers and get all sorts of new business!” that’s better.
And if they say “We will crush our enemies, see them driven before us, and hear the lamentation of their women,” well, perhaps you’re focused a little too much on beating the competition. But don’t worry–developers like that eventually grow out of it, and go on to become the governor of California.
