How was writing a novel like a QA project?

"I see from your resume they you wrote a novel?"

The final week with my previous employer was also the week I published my first novel "Rivers End" on Amazon and Kindle. After a five-month process of writing and editing, I had a final draft I was proud to publish. I'd noted this in one line at the bottom of my resume next to my newspaper work and volunteering, just thinking of it as a bonus to my professional skills and experience. Then came the questions. Every interview. After a couple interviews, I took it off my resume. I didn't want to distract from what I feel is a solid decade-and-a-half-plus in all facets QA and SDLC.

It was at an interview where someone had my "old" resume a couple weeks later when I was asked: "How was your writing project like a software development process?" I was pretty well-trained in handling about anything from the interview process, be it logic problems or being asked to write SQL queries on a piece of paper. It didn't take long for my answer to snap into my brain.

It took me the first two and a half months to write Rivers End. I worked on it nearly every night, except for a few nights during a business trip to Oakland (since I was mostly working during night hours there - although I did come up with the locale of one chapter from that trip). The writing process was requirements (my outline and character sketches) and coding (the writing based on outline) with my unit tests coming at the end of each chapter where I would simple "test" that each chapter's subplots and conversations fit into the scope of the story (keeping in mind the story is non-chronological and certain parts of the past are revealed later in the timeline of the story). There were times where I "commented out" parts of the book which were cut totally or used later in the writing process.

I was surprised that I had a finished draft in such a short amount of time. The finished draft was my QA version. As surprised as I was about how fast I could write a 200+ page novel, even more surprising was how much time and effort it took to edit it. Lesson learned: better character sketches, more detailed outlines and writing slower! No marathon writing sessions until 2:00 a.m. - take notes, finish after work the next day.

I relied on different "QA" editing methods. First of all, I had a few "beta" readers read through and submit some pretty glaring errors (spelling, grammar, repeated sections). I also re-read myself, from the context of knowing the end of the story. I had to pull out quite a substantial part in the middle of the manuscript and completely re-write it, putting a character in a different place at a different time. This was definitely a "missed requirement". I also had two people completely read hard copies of the manuscript and manually mark-up the errors and questions they had. This lead to the challenge of "versioning". My QA background was a huge help. I found myself naming versions that included corrections with names like B.1, B.2, C.1, etc. Some people found the same "defects" twice. In the scope of writing and with a very loose, self-driven deadline, there were no "defects" I'd allow in - removing a major and difficult software process of releasing code with known deficiencies.

After almost two months, nearly as long as it took me to write the book, I had a finished product. And that is something I could say would have been a lot more challenging and probably of lower quality if not for a background in quality assurance and software development lifecycle. After answering that questions, I decided to put the novel back into the resume. Much like many of the successful releases and product launches where I have contributed, this too belongs in a resume as an accomplishment and I've returned it right at the bottom where I'd originally placed it. If anything it shows dedication to completing a quality product.

The Finish Line Keeps Moving - Toward Perfect

A bit about this blog. I started putting this together in summer of 2014 while looking for a job and trying to promote my book Rivers End. I'll be discussing the aspects of writing the book, aspects of software quality management and other relevant topics from previous and current professional experiences.

The blog is called "The Finish Line Keeps Moving - Toward Perfect" - reminding me of something I'd once heard on a project while at an employer. After three or four missed deadlines and a software release that was scheduled to include 15-20 defect fixes and enhancements, the release had grown to a 120-130 defect fix release with 10 enhancements and new builds were coming out daily. For every three or four items fixed, one or two defects were introduced or discovered. The release was like plugging up holes in a dam just to have others refill - but still moving closer to "perfect" or a tangent of perfect. We talked about the end of this release as "The Finish Line" and I joked "The Finish Line Keeps Moving"- my boss at the time's response was "Moving - Toward Perfect".

If the software development cycle is a race and the finish line keeps moving it's more like a basketball game than a race; there is always a clock ticking with the deadline where moving parts are supposed to intersect like planets lining up (especially when the release is a confluence of releases of integrated parts) - and the state of the software when those "planets aline" is the finish line. But like basketball or football or soccer, the clock continues to move, regardless of the "score" of the game.

With publishing the book the deadline was something I set with myself with flexibility. There was no moving part (although I happened to finish the book the day I was laid off - purely coincidental) to coordinate when writing the book - but versioning and editing as the final draft was produced was a QA process of its own (something I will elaborate at some point in this blog.)

The software development process is not just a race or a timed event but also an evolution. As employees we work on evolving software through development (which when done properly is a natural selection of that increases sell-ability and client happiness - something so many companies seem to overlook.) Too often I've seen product requirements, managers or "the upper level" fall in love with an enhancement or project like a child and force it into software - something the world (the client base) doesn't want. It's a false evolution - not quite like rabbits in Australia, more like the inbreeding of dogs to product exaggerated features - usually leading to deformities. Evolution is about moving on from bad ideas, cutting the losses at times and growing - learning. Same is true for the employees. Someone who is invaluable at one point in a company's history can work at maximum effort and still become valueless. It's not something the worker usually sees. We must continue to evolve.

Thanks for reading, keep moving and evolving. Now can only happen once regardless of how the parts move around us.