Applying The Creative Writing Process to Software

Grabbing the best ideas from other industries and applying it to your own is a fantastic way to learn and discover new ways to do things.

I was listening to the Tim Ferriss podcast yesterday in an interview with Neil Strauss.  Two best selling authors discussing their creative process for writing a book.  It got me thinking if some of the approaches they discuss could apply to to software development -which is also a highly creative process.

Let’s break down Neil’s process a bit.

The first part is to do a lot of research.  For example, when Neil is doing an interview with a celebrity, he will read everything they’ve written, listen to ever song, devour every bit of information he can about the person.  He writes out a list of 100 questions for the person and studies it like you would for exam prep.  Finally when it’s time for the interview he puts the questions in his back pocket and forgets about them.  As a result of this level of preparation and study the interviews can flow naturally.  He has a backup of questions to draw on if the conversation stalls but usually he can riff off the bulk of knowlege he has collected to build rapport and get to the really interesting details.

With a cache of notes from research it’s time to start writing.  There will be several drafts and the goal of the first one is to “Write to the end”.  Convert the pile of notes into a story as quickly and rough as possible without self editing along the way until you get to the end of the book.  This first draft will be read by no body else.

After the first draft you are just 1/4 the way finished.  The second draft is done for the readers.  You cut out all the uninteresting pieces, ensure the story arc is solid, characters are developed enough, flow is good, and jokes are funny.  You do this by putting on the hat of a reader and ruthlessly editing your first draft.

The next step is to put on the hat of a hater.  To deflect criticism before it happens you go through it again with the perspective of someone who wants to debunk your stuff and criticize your ideas.  At this step you fact check everything, and make sure there’s nothing offensive, or at least that the counter points are acknowledged and dealt with.

Finally it goes to the editor and is test read by anyone who wants to read the manuscript. Listen to their criticism, and adjust your book to improve things and cut parts that people don’t find interesting.

After enough feedback you’ll know when to lock down the book to a final version and send it to be published.

For an average size book this whole process can take upwards of a year to complete.

There are some lessons that we can take from the best approaches to writing books and apply it to writing software.

Notice that this approach to writing a book is not Agile, and it’s not waterfall, it doesn’t involve sprints, scrums or user stories. It’s completely unique to the way most software is created.

The first part of Neil’s process is research.  You might roughly correlate this step to requirements gathering but that vastly understates the effort Neil goes through.  I have never met a developer that thoroughly masters the domain knowledge before typing anything the way Neil does.  Taking months and often years to interview people, take courses, and generally immerse yourself in the space you will eventually write about gives you skills and knowledge to be able to write “to the end” without pause.

Side note: Interruption is one of the most detrimental things to the creative process. Stopping to look something up, or ask a question of the client can waste half a day of productivity.  Agile methods promote this open communication during development… maybe there’s a better way.

Writing to the end for the first draft is something not possible without having enough domain knowledge to do it in the first place..  There really isn’t a comparable product in any software project I have personally worked on which compares to this first draft.  The scope of Neil’s first draft expands far beyond what is in the final book as he will likely cut 50% of the pages during editing.  It has me wondering if it would be a good software development approach to rip through a 20,000 line first cut of an application knowing that I’d delete 1/2 of the code before being finished, slashing out features along the way.

If we did write this quick rough first draft application with the intention of whittling away anything superfluous to arrive ultimately at a publishable product then the next step would be to put on the hat of someone who wants or needs to use this software. Can you make the interface more intuitive? Can you give it some life? Are there any features that are more complex than they’re worth? What can be cut without destroying the utility of the application?

It would be only after these changes have been made that anyone other than yourself would see a demo.

In Neil’s process the final step is essentially debugging. Going through the application yet again with an eye for correcting errors, fact checking things, getting a lawyer’s review for liability etc.  At this point you would also ask for the input from as many test subjects as you can, gathering and filtering feedback to fine tune rough edges.  Essentially you want to make sure that if someone is trying your software they don’t have a reason to ask for a refund and they can’t claim that you or your company are incompetent.  The final product has to be great.

Only after enough friends, family and colleagues have used the software that you feel confident in it do you call it done.

It’s interesting to wonder if this would produce a better product than the typical agile developed software.

There are a couple of significant differences in software vs book writing however that need to be addressed.  Software is rarely a single developer’s sole project.  There is usually a team to divvy the work between. This team adds some communication load to the project as people need to be in sync.  This team approach doesn’t work well if all the domain knowledge is stuck in scribbled notes and in the head of  one guy that did the research.  Would Neil’s approach scale to writing a 10,000 page book with 4 other writers?  The counter point would be that if you’re looking at writing a 10,000 page book maybe it would be better to write 20 500 page books and only have a single author per book.

Software is also not written linearly.  When you start to write a book chapter you may be able to start writing and continue without stopping the flow of words.  You probably wouldn’t be halfway through chapter 18 and realize that it would be good to foreshadow what’s happening earlier, then stop and go back through to find a good spot to add that foreshadow element to an earlier chapter. A disruption like that would completely disrupt the flow of your writing.  It’s difficult to write software without jumping around like that.

Programming languages are much more rigorous than English.  it’s not always possible to skip pieces where you need to know an answer to get a working program. There can be hard dependencies that prevent you from moving on until they get solved.  Again this is an opportunity for interruption.

It would be interesting to try this method on a software project to see how it translates.

If you are interested in getting more details from Neil Strauss and Tim Ferriss about the creative process check out this video: