Save the Cat as a Design Template

Following our analogy between writing software and writing stories, we can gain additional insights by exploring the use of design templates. 

Back in the early days of information systems development, say the early1970's, nearly all software was written a line at a time using a programming language like COBOL, P/L1 or C.  Over time developers realized that certain functions such as a sort routine or a mathematical function were being written over and over again, by each programmer who needed them, leading to a great variation in software reliability and added expense due to the enormous duplication of effort. Eventually, these common functions were collected in software libraries. Fast forward to today and one of the most popular programming languages, called Python, allows software developers to do a small amount of traditional programming while pulling the vast majority of needed functionality from existing libraries. I hope I haven't gone into too much technical detail here. But, I wanted to show how you can go from writing everything from scratch to assembling it from existing reusable components. And I wanted to show this because the same thing is possible for writing stories.

There are simple templates for writing stories that provide heuristics for the major components of the story such as: You want the reader to be able to identify with the protagonist. All primary characters must be believable people. You must keep the reader interested by revealing the plot in a way as to keep their attention. And so on. And while those are helpful, they leave a lot for the writer to do. This is not a bad thing, as the writer should be contributing a lot to the story. But, there are stories written for different purposes. I mean no disrespect by saying that there are junk food stories to satisfy some readers who want entertainment and emotional stimulation. And there are haute cuisine stories for people who are looking for something deeper and more satisfying. For junk food stories, it is way too much effort to write them from scratch, and more sophisticated templates are needed to leverage the writing process.

There is already at least one reusable template for a story which is widely used. It is called Save the Cat by Blake Snyder, and it was introduced for screenwriting. It focuses on movie and TV scripts but has been applied to novels and other story vehicles as well. Having a template like Save the Cat provides several benefits. It provides a structure for writers so they don't have to develop their ideas from scratch. It provides a template to facilitate the evaluation of scripts so the people who buy scripts can go through them more quickly. And, it provides the audience with what they are expecting.  

The Save the Cat template is extremely popular at present and its advocates make it sound as though anyone who does not follow it will never get any scripts accepted or novels published. This may very well be true for the popular market but there are two additional things that one must consider. First, not all writing targets the popular market. Some writers wish to achieve something different, perhaps more literary. Perhaps they want to try something more novel, no pun intended. Maybe they want to tackle one of Jane Austen's novels in the style of Henry James. Maybe they just want to write what they want to write, popular markets be damned. 

The second problem with the popular market is that it is fickle. If you followed television from the middle of the 20th century you would see detective stories, followed by cowboy stories, followed by stories about hip socially aware characters. When detective stories rule, just try to get a cowboy script published. As a thought experiment imagine trying to get a popular show from the 1950's accepted in the 1970's, or vice versa. Would the Beverly Hillbillies sell today? Would All in the Family have attracted an audience in the 1950's? 

The problem with chasing popular tastes is that popular tastes change. And if the only thing you know how to do is target current popular taste, then you are in deep weeds when tastes change. Imagine trying to sell a script that does not provide the audience with a satisfying ending. What if the last episode just fades to black? Oh, wait, is that what the Sopranos did? Yeah, it worked well for that show. But, I doubt that many other shows will follow suit.

For those who find the use of templates repugnant for quality stories because it constrains the writers creativity, I would respectfully suggest that the writer can put their creativity into the parts of the story that can benefit from it the most while tweaking existing templates for elements that are less important. No point in reinventing the wheel in different shapes and colors when you can put that energy into new ways to use the wheel.

The point here is that templates provide some amazing benefits while also introducing some significant risks. But, what if there were numerous templates and one could choose the parameters of the story they are trying to write, feed them into a piece of software and let the software generate the script. Let's take this  a step further and say that the software is intelligent and it can figure out what needs to be and then does it. Hmmm.. this is starting to sound like artificial intelligence writing stories. Is that possible? Well, just wait till the next post.

Writing as an Evolving Prototype

 Once you see writing as a design and development activity analogous to writing software, you begin to see how some lessons from software development can be applied to writing stories.

Back in the early days of software development, say the mid to late 1970's, most software development followed a widely accepted process model called the life cycle model or the waterfall model. On paper it was fairly straightforward. The steps in software development were (roughly): requirements, analysis, design, coding, and testing.  Sometimes steps were merged such as in requirements analysis, analysis and design, or coding and testing. The lifecycle would require several years and millions of dollars before the users of the system saw anything concrete and upwards of 75% of the time, they were not happy with what they saw. So, a new idea in software development began to emerge.

Innovative developers began building smaller pieces of the system, showing the smaller pieces to users, and getting feedback much sooner. In hindsight, it seems obvious. But it wasn't. I was involved in several of these projects and the advocates of traditional development models resisted this new approach like the plague. They claimed that all these smaller pieces were throw away pieces and hence a waste of time and money. They advocated building the entire system and then fixing problems in a phase called maintenance. 

Those in favor of building smaller pieces came up with a name for their approach. They called it prototyping. And, in response to critics who called it throwaway software, they started calling it an evolving prototype suggesting it wasn't throw away. It was evolving into the final product. Prototyping became increasingly more popular while lifecycle methods became increasingly more formal. Eventually, developers began to notice that prototyping worked well on certain kinds of software development while more formal methods worked well on other kinds of software development. And they even discovered the key difference. 

On systems that were well understood, the lifecycle models seemed to work best. On systems that were not well understood prototyping seemed to work better. Prototyping is a means of gathering requirements and understanding what the user wants. If you already know that it is much more efficient to just write down what you want and have the developers develop it. Again, all this seems so obvious in hindsight. But it took decades to become obvious.

So, we have two factors to consider here: certainty and efficiency. And we can apply this gem from software development to writing stories. If you know what you want to write and know how to write it, then write down your outline and follow it to write your story. This is commonly known as the plotter approach. If you are not sure what you want to write or are not sure how to write it then you need to try something. This is commonly known as the pantser approach. Or, if we wish to give it a more dignified name, we could call it the evolving prototype approach. 

Thinking about writing fiction as analogous to writing software provides and additional benefit. We wish to write our stories as efficiently as we can given our level of certainty regarding what we are trying to achieve and how to achieve it. In an earlier post, I said "the work of writing is reduced by working out the design to determine the structure rather than by having it emerge through rewrites." This still holds. There may be things we are certain about such as how to write a particular kind of character. While there are other things we are not as certain about such as how to best describe a setting that we have never actually experienced. In this case, you should focus on reducing uncertainty wherever we can. And then crank out the parts where you have a high level of certainty later. The reason why this order is most likely the best is that the reduction of uncertainty in some aspects of writing the story may create uncertainty in other parts.

Another thing we can take from software development is that you should understand the difference between Learning vs Performing. When you have high levels of certainty regarding what you want and how to achieve it, just do it. This is the most efficient way. We call this Performing. When there is uncertainty in what we are trying to achieve, there is stuff we need to learn or figure out before we can proceed. We call this Learning. If you try to Perform when you need to Learn, you will just reduce uncertainty in the least efficient way.

One final word. This is not intended to be set in concrete. You should tinker with it to make it work for you. Each writer is different, and each story is different. Just do what you think is best and if you make a mistake, learn from it.

Design Thinking vs Analytical Thinking

 I would like to start this post with a relevant digression and then return to story design.

Early in my career, I worked in software development. Writing software and writing stories have a lot in common, although it is beyond the scope of this post to explore that in any detail. I will, however, provide a few examples along the way. In fact, here is one. The hierarchical decomposition with step wise refinement that I discussed in the last post comes straight out of software design.

Nonetheless, in the world of software development you would start with a business problem, go through a process called analysis and design, and then turn it over to programmers to write the software. The people who did analysis and design were often called analysts and they often saw the results of their analysis as the input to the programmers. If you asked an analyst when they were doing analysis and when they were doing design, they would give you an odd look because, in their minds, the two were simultaneous. But sadly, they are not, and this was probably why the first few decades of software development were characterized by massive cost over runs and abundant user dissatisfaction.

Analysis and design are two distinct activities requiring different cognitive skills that may occasionally be found in one person although that is not common. Analysis is the process of decomposing an existing phenomenon in order to understand it better. Design is the process of constructing a solution to a given set of objectives. It is generally true that if a person is good at one kind of analysis, they will be good at another kind of analysis. And if they are good at one kind of design, they will be good at another kind of design. We can consider a few examples to establish the difference between analysis and design more concretely.

Let us begin with a simple personal problem that most people can relate to - your social life is not satisfying. What do you do? Well, you begin by determining what the underlying problem is. I am going to offer a few common reasons. Your life is just not interesting enough. You don't have ways to fill your free time. You don't have enough friends. You have friends but they are not satisfying enough. In the analysis phase of this, you would examine your life closely and try to determine which of these (or something else) is the problem. The first and most crucial step in solving a problem is figuring out what the problem actually is. 

Once you have identified the problem, you can take steps towards solving it. Consider how very different solutions to the problems listed above might be. Also consider how unlikely it would be to solve the problem if you were just trying different things. People often jump to solutions before understanding the problem which is a very hit or miss approach.  Now let us take a more complicated example.

In this next example, we will consider a business problem. Advertising costs are going up while sales are going down. We actually have two problems here that may or may not be related. How do we find out? Well, since we are trying to better understand an existing phenomenon, analysis of the situation is required. We need to determine why advertising costs are going up and why sales are going down. 

There are many reasons why advertising costs may be going up. Perhaps we are using the wrong advertising firm. Perhaps we are inefficient in reaching our target market. Similarly, there may be many reasons why sales are declining. Perhaps our products are out of date. Perhaps, we are appealing to the wrong market. Perhaps our products are too expensive or too poorly made. Perhaps it is a combination of the two. In order to find the answer, we must do some analysis of the current situation. 

Once we understand the current situation, we must come up with some solutions. Solutions don't exist in the world. We need to construct them according to some set of objectives. We may look for a new advertising firm. We may try a different advertising medium. We may more carefully target our prospective buyers. If everything looks good on the advertising side, we might decide to come up with ways to improve sales. We might need to update our products. We may need to change our pricing or ad some incentives. It may be that the problem is a combination of the two and the solution is going to be more complicated. 

Now let’s consider this process for a novel we are struggling with. In the case of sales and advertising there are fairly well understood places to look for problems. And the same is true for writing a story. Is there an overarching message or theme? Is it compelling? Is it clear? Are the characters interesting? Are they relatable? Is it set in the right kind of setting? Is the setting well presented? Does the plot move along at the proper pace and are things revealed to the reader to keep the reader interested?

In the advertising and sales example, we barely scratched the surface of what an expert in this area needs to know. And in the writing example, we similarly barely scratched the surface. If you are an experienced writer, you may want to make a list of things to consider. If you are less experienced, you might ask someone to read it and make suggestions. Or you may wish to read some books on writing that are written for new writers. They are full of things you need to consider. But remember, the purpose of the analysis phase is to understand the problem. The purpose of the design phase is to come up with a solution. So, let me emphasize this next point.

Don't jump to a design (solution) until you fully understand the problem.

Perhaps your protagonist is a bit flat. So, you decide to make him a wealthy playboy and get busy modifying your story accordingly. But then you decide the wealthy playboy doesn't work so you try making him a well-meaning public servant. Will this work? This is what happens when you try to solve the problem through trial and error instead of designing possible solutions and thinking them through. In the world of software, this is called prototyping and, as we shall see in the next post, it is the costliest way to find a solution. But, in understanding prototyping, we can understand something very important about writing stories. While prototyping is a costly way to proceed, sometimes it is the only way to fully understand the problem.