Is Writing a Book Similar to Developing Software?


Is Writing a Book Similar to Developing Software?

I recently started writing a book that I have been meaning to write for many years now (non-fiction, science + philosophy). I am only about 20% done, so I still have a long way to go, but already some interesting patterns are becoming visible.

Having been a software engineer for most of my life (Really! I have spent more than half my life as a programmer!), it was inevitable that I would wonder how writing a book compares to developing software. 

In fact, it was my experience with developing large software products that gave me the confidence to tackle writing a book in the first place.

Anyway, so here it goes: What are the similarities and differences between writing code and writing a book?

Some Similarities: Planning, Prototyping

So far, the biggest similarities have been in planning. Software products as well as books are typically written with a customer in mind, so trying to figure out who the customer is, their demographics and likes and dislikes, why they would want it, how to make it appealing to them, and how to actually reach them have all been very similar.

The next step was creating an initial “prototype”. Coming up with an initial seed of an idea, doing some quick research to see what currently exists out there, and convincing myself that this is worth pursuing further have been very similar.

Of course, the “prototype” in the case of a book is a bit different from a software prototype. 

In the case of a book, particularly a non-fiction one, one normally starts with an abstract, an index, and one or two initial chapters. In fact, I hear this is basically what typical writers send to publishers to see if they are interested. (I may not do that, more on that later.)

And, just like software prototyping, this also involved much writing and rewriting. I think I have already rewritten my abstract and index like 5 times! The basic idea and theme remained the same, but trying to figure out how to structure it and how to position it for the customer has been a challenge. 

This is partly because it is a non-fiction book rather than fiction, so typically it requires a higher level of targeting and motivating the reader. (The analogy with software would be a productivity app vs a game.)

I actually struggled quite a bit on that. I really wanted to write fiction, but during the prototyping phase itself I realized that this was a much bigger challenge than I was able to handle, given that I am still an amateur.

The compromise I have reached for now is that the book is non-fiction, but it will contain a bunch of stories and parables. I think I can handle stories and parables quite well, but an entire novel seems a bit out of my reach at the present.

While I have a relatively complete “prototype” at this point, I am still not confident it is good enough. Or even whether it will appeal to the right audience. (This, again, is no different from developing a software product. Until you have your first few customers, you are never sure.)

But this is where the differences start to emerge.

Big Difference: No TDD!

In the case of software products, it is relatively easy (and in fact necessary) to develop “unit tests” at the same time (or even before) writing the code. This is generally known as Test Driven Development (TDD). Unfortunately, there is no such thing for books!

Validating what I am writing, as far as whether it “works”, is cohesive and meaningful, and whether it will appeal to the right customer, is a very painstaking, slow, error-prone, and highly biased process.

In fact, given that I am a software engineer, I’m wondering if there may be an idea for a software product in here: an automated AI / NLP based testing tool for writers! 

Something where you can judge various attributes of the writing, such as how approachable, cohesive, compelling and fun it is, whether the progression is meaningful, whether there are any loose ends, etc. 

Possibly also some way to specify the intended audience, so it can judge if the targeting is appropriate, and so on.

Basically, it would generate a representative “test reader” from the intended audience who will give you specific and actionable feedback on your writing.

This would actually be a great boon for me right now. One of the things I love about developing software is the state of flow you can get into when you are going through the edit / test / debug / fix loop over and over.

This is unfortunately not happening while writing this book and has been a major drag on my productivity level. I feel like I should really look into developing some way to automate testing here.

Of course, one of the methods that appears to be common among writers is to pair up with a buddy writer. Then, you can both act as each other’s customers and provide timely feedback. So I guess I need to find a buddy!

This is Just the Beginning

What I have listed here are just a few of the most striking things I have noticed so far. As I move forward, I’m sure more similarities and differences will come into light. 

I’m sure there will be the usual ups and downs of working on a labor of love: the initial fits and starts, the mid-product slump, the excitement and despair roller coaster, the hard grind to get through the last stretch, the final dotting the i’s and crossing the t’s, and so on.

Also, my current plan is to self publish, which is similar to someone releasing, say, a game or app as an indie developer. So this will involve finding the right portal to publish it to, interacting with the community there to gauge and generate interest, finding some “beta” testers, iterating with them, and so on.

Anyway, that’s a long way away. As I said, I’m only about 20% of the way so far. And we all know the old saying in the software world: The first 80% of the product takes 80% of the time, and the remaining 20% takes another 80%! I’m sure that will apply here, too!

We’ll see how it goes. It’s going to be an interesting ride. Of course, I’ll keep you posted!