Anupam Krishnamurthy

What writers can learn from software development

Nov 2018

Over the last twenty years, the software industry has transformed itself to innovate at lightning speed.

Amazon and Google refresh their websites several hundred times a day. Way back in 2011, Amazon's mean time between refreshes, was 11.6 seconds. These tech giants operate like large organisms, constantly renewing and upgrading their hardware and software. Your body replaces 100 million blood cells every minute without you feeling a tickle. Similarly, Amazon's constant upgrades under the hood will not disrupt your search for band-aids with Shakespearean insults or this Bojack horse mask.

This rate of innovation sets the software industry apart. Few other fields can work in this manner - I'd like to meet the mechanic who can remodel your car as it is being driven to work. But what has that got to do with creative writing? What can building innovative software teach us about writing?

To get there, we need to revisit a time when the software industry wasn't this way. All of this magic happened when it moved from the realm of construction to creation.

The process of construction

We create art, but we construct bridges.

Construction is what we do when we already have a fixed plan and need to execute it. With bridge construction, a large chunk of work happens before we lay the first brick.

  1. List out the materials required and draft a construction plan.
  2. Determine where the pillars should go, the type of soil under them and the load they can support.
  3. Survey the span that needs to be bridged and select the right type of bridge.

Before we specify, double check and budget all of this, the physical construction of the bridge cannot commence.

It is crucial to have the plan drafted out in exquisite detail before building a bridge. If one calculation were off, we would be risking people's lives. It is better to be slow and right rather than fast and wrong.

That is how construction happens.

Traditionally, people built software like they built bridges. First, they described the problem to be solved. Then, they designed a solution and wrote down detailed requirements. They finalized and signed off these documents before they wrote a single line of code. Just formulating the requirements could take anywhere between a couple of months to half a year. The waterfall method of building software worked this way.

However, constructing software was a failure. One oft quoted study looked at US Defense Department software projects, back in 1995. Of $37 billion USD worth of projects, it reported that 46% of the systems were never used, and another 20% required extensive rework.

Building software like a bridge presents a few challenges. The methods used to build bridges have changed little in the past 200 years, whereas the software industry transforms itself every year. With software development, detailed planning before execution does not work well. Developers observed that:

Construction wasn't the best way to build good software. Enter creation.

The process of creation

Creativity is novelty that works.

The pioneers of agile software development were frustrated with the waterfall method of constructing software. Rather than drafting elaborate plans and documents, agile encourages building software in iterations by validating or rejecting hypotheses. Agile projects are 2x more likely to succeed and 1/3rd as likely to fail as traditional waterfall projects.

Let me illustrate the agile methodology applied to an app where people could shop for groceries. At first, the team would list out their hypotheses on features that would benefit their customers:

They then build basic versions of these features and test them out with some of their users. They may discover that only 1% of their customers cared enough about 2 hour delivery. In contrast, 20% may prefer to choose which supermarket their groceries came from. This way, they can figure out what is valuable to their customers and discard what is not, without investing all the effort upfront.

In contrast, under the traditional approach of software development, a company was likely to conduct extensive research and build out detailed features over several months only to see that their customers didn't quite use them.

Agile isn't about being right. It is about rapid trial and error, and incremental movement towards the ideal . It turns out that this process of trial and error is governed by a neat little thumb rule.

The 80:20 rule

Vilfredo Pareto, the Italian economist, observed in 1906 that 80% of the land in Italy was owned by 20% of the population. Once he made this observation, he saw this pattern everywhere:

Using this rule, Jeff Sutherland, created scrum, a popular agile framework. He noticed that 80% of value in a software resulted from 20% of its features. His method gets us to develop the valuable 20% first, get feedback on it and build out the rest.

The difference between creation and construction is that the creative process is inherently random and follows the Pareto principle. Creation would not work well with bridge building, where an iterative process of discovery would soon end in disaster.

But it could work well with writing. Writing is a creative process that is closer to software development than building bridges.

We write like we built bridges

When do writers write? Is it when their ideas are well laid out? Is it when their research is complete? Is it when preparedness meets a moment of inspiration?

The bestselling author, Daniel Pink, tells us to write to have ideas. Most great writers find out what to write about, by writing. Their observation of the world gives them a hint, which they pursue like bloodhound on a trail, by putting words on paper. Pink's process of discovering a book is to write a book proposal about it. He writes at least 30 pages to build an idea worthy of a book.

School teaches us to converge our writing to an expected answer. Teachers then grade our answers. Every question has a right answer. Before we set our pens to paper, the approach to our answers needs to be clear in our heads. And then, we write down what we know to the last detail — much like building a bridge.

With academic writing, the goal is to be homogeneous. To meet certain specifications like a finished product in a factory. With creative writing though, value lies in divergence. You offer your unique point of view. Like a sculptor who works with his hands.

The key to writing better is to move from construction to creation. Our creative writing needs to make the shift that the software industry has done with great success.

5 ways to create with your writing

1. Write badly

I put this point up front to emphasize it. Good writing is a product of a lot of bad writing.

The creative process is random. Every great writer has typed out pages full of prose to discard them. The solution is not to give up, but to keep at it. Stephen King once scribbled an idea for a story and tossed it into the bin, when his wife picked up the pages and read them. That story went on to become Carrie, his first blockbuster novel. Thereafter, he had an epiphany:

Sometimes you have to go on when you don't feel like it, and sometimes you're doing good work when it feels like all you're managing is to shovel shit from a sitting position.

Good software development entails drafting several features, but building out the few that work. Good writers would rather write badly than not write. After some bad writing, the good stuff will flow. One must retain this faith.

2. Focus on the 20% first

"Front loading value" is a phrase that gets thrown around in software development. It implies focusing on the 20% that delivers 80% of the value first.

Use the Pareto principle to get a rough draft of your work in an uninterrupted flow. Do not hesitate to be wrong. Do not hold back your wildest ideas. Just get them all on the page. Chances are that the first draft of your idea would contain 80% of its value with 20% of the effort invested. Once you have gotten all your ideas on paper, you can worry about fine-tuning it.

I have written about how you can do that. The key is to separate your writing from your editing.

3. Improve in increments

Software is developed in increments as value is realized. Similarly, return to your draft and improve it in increments. Support your points, with an example or two. Use metaphors to illustrate your stand. Throw in a joke or use a famous quote.

But do all of this after your first draft is written. Do not drift off into the internet in search of a joke midway. Because, we know what happens then. One of Zadie Smith's 10 rules of writing is "work on a computer that is disconnected from the ­internet".

4. Seek feedback

In a beta test, companies test software by rolling it out to a sampling of its intended audience. These days, it is possible to beta test your writing. Several writing communities let you share your drafts for member feedback.

If you have a generous friend or partner, run them through the idea you have written down and get their feedback. Daniel Pink reads all his books' numerous drafts aloud to his wife. If you thought that was generous, he then has her read it back to him, often admonishing her for not using the right tone. It is little wonder that most authors dedicate their work to their partners, with Ernst Hemingway giving each of his four wives the honour.

5. Focus on process rather than product

By moving from waterfall to agile, software development has gone from focusing on a finished product to following a process to get there in increments.

Product centered approaches are risky. This is because creative output is random. Our product can fluctuate in quality without the slightest warning. Sometimes, we reach the desired quality in half-an-hour of inspired writing, and other times, we agonize for several hours without anything to show for it. Do not define success around the quality of your writing. Banking upon the quality of one's creative product is much like investing in one stock in the stock market.

In a process based approach, we define success as following a regimen. This could be writing 500 words everyday, or spending one hour writing everyday, regardless of the quality of output. By writing everyday, we churn out a great piece every now and then. This is analogous to investing in a balanced portfolio, where good stocks eventually outperform the bad ones.

Creation is fun

The whole difference between construction and creation is exactly this: that a thing constructed can only be loved after it is constructed; but a thing created is loved before it exists. — Charles Dickens

Creation is fun, and there has never been a better time to create. Thanks to the internet and some quality software development, our creations can be published in Berlin and accessed in Auckland within the whisker of a second. Every one of us can catch this wave and experience the joy of creating.

And yet, not many people's idea of a fun evening is to spend four hours writing. The main reason is that we have been doing it wrong. We construct most of our writing rather than create it.

As one of the greatest writers of all time points out, creative writing can be fun before, while and after it happens.

This essay was first published on Medium.