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.
