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.