Tag Archives: software

Ship It! The Rookie Writer’s Dilemma

When I’m not fighting crime writing fiction, I’m writing code: good old-fashioned, rocket-fast, wicked cool code. Also, sometimes boring code and long tech specs. There are a startling number of parallels I’ve found between writing fiction and writing code, and one of the biggest ones of them is the “Ship It” urge. Some background is perhaps in order.

I used to work for a little software company in Redmond. You may have heard of it. That company is known for a high level of polish on its code; say what you want about its programs, haters, but for huge software products that are used by almost everyone on Earth, very few real bugs are found. They have perfected an iterative cycle of code and test, code and test, code while testing, that successfully cranks out very solid products. To give you an idea of how big a deal this is, imagine publishing the most popular book in the world. Imagine that it’s over 1500 pages, and before you ship you need to know that there are absolutely no typos, no logical flaws in the story, that you got every detail about ships and horses right, that there are no anachronisms (Anyone have zippers on pants in the 1700’s? You fail.), and that the style is consistent and engaging throughout. Now imagine that half the planet is going to read your book, thousands and thousands of people are going to critique its every nuance, and the future of your company depends on you writing that solid a book. It can be done, but it’s not easy. It takes a process, and my old company has one.

Most other software companies imitate that company’s software engineering method to a degree. It is very deliberate, and I learned early on that the biggest “company secrets” I was ever privy to were planned features and release dates. If you are selling software, those are the last two things you ever want to tell the public (if they are paying attention to you). Another little software company in Cupertino has perfected the art of telling the public nothing until the product is already on the assembly line. They do this for a reason – if you say you’re going to have feature X in the product shipping in October of next year, it may be the case that come next May, you find out that feature X is very, very hard to do, and the product needs to go on without it. Feature X may cripple your product because of how big or slow it is, or it may not be as cool as you thought, or you may just not be able to figure it out. All of those things happen in software. Hence, the process goes like this. On day one of product planning, you (or a room filled with blind monkeys marketing professionals) make a list of all the features you’d like to have in the next release, and pin a date down for when you’d like to release it. You also pick a series of “measurement dates.” As you get to each of these, you look at your progress and find what is and what isn’t working. For the things that are behind where you’d like them to be (and again, you can often only guess at how hard it is to write a feature, much like in fiction you can only guess at how easy writing that fight scene will be), you ask yourself – “Do I really think I can catch up?” Better yet, you assume you can’t catch up, and instead you ask yourself, “Is it worth delaying either the release or other features to get this done?”

You do these measurement steps as often as you can (though there is a point at which measuring is taking more time than it is saving), and eventually you’ll find that you can’t quite get to all the features you had planned for the next release in time for your target release date. You then decide to either delay the release or drop/pare back the feature. When your release candidate does roll around, you almost always find that 1) it took longer than you had hoped, and 2) it doesn’t have all the features you planned. This is why you never tell the public which features you are adding (unless you really need to, and then those features can’t be dropped, which is a dangerous attribute for a feature) and you never tell them when you plan to release until you are really, really sure that you can make the date. This should generally be whenever development is winding down and you are mostly in bug-bashing/user testing mode.

If this sounds complicated and easy to screw up, that’s because it is. Companies do it all the time. The company I worked for doesn’t do that very often, and the result is that when a product ships, it is a Big Deal. You have parties. If your project is big enough, you have parties that include people only tangentially related to the product, because, hey, you just shipped a terabyte of working, awesome, cool code that consumers are going to love. Often you’ve spent the last N years of your life working on just that code. It’s a good reason to have a party. When you “Ship It,” everybody involved gets a Ship It award. When I was there it was a cool plaque with the CEO and company founder’s signature on it next to your name. It’s a nice touch to celebrate a genuinely huge accomplishment. Shipping code is always an accomplishment.

Similarly, “shipping” fiction is a Big Deal. I worked on my novel for three years. There were points at which I didn’t think I was ever going to finish. There were other points where I thought it was crap that wasn’t worth finishing, and there were some where I just thought I was wasting my life. After all of that, though, I stuck with it and put together a novel that I am really, really proud of, and this past February, I got to write “The End,” (and then promptly delete it because nobody actually writes that in a book any more). City of Magi has been sitting on my virtual shelf ever since then, waiting as it cools for me to get some distance so I can come back and mercilessly edit it. I can’t deny, though, that there is a huge part of me that wants to just “Ship It.” I want to get to the stage where I’m shrugging off rejection letters, checking my mail hoping for that one agent to say that they’re ready to represent me, or better yet a publishing company that wants to put what I wrote on real, live bookshelves. But the fact remains, City of Magi isn’t ready. It needs an edit. And after that, it needs an edit. Maybe, maybe, after that it can go out to agents and publishers, who will of course say that it then needs an edit. I can resist the Ship It urge because I worked on City of Magi for three years and it is the coolest thing I’ve ever written.

While my novel is cooling, I decided to write serial fiction to be published in the great new world of epublishing, and that took off much faster than I ever figured it would. Now I’m sitting on two complete-ish issues of Those Who Die Young, and wondering… do I Ship It? How polished is polished enough? That’s the truly terrifying thing about epublishing: you are the publisher. Is it ready? Who do I ask? Ultimately – no one. I decide. And that authority is terrifying. The software engineer in me wants to cut any scenes that I’m not 100% sure of and publish, but there’s a risk. This is my first major foray into publishing fiction. Everything I do from here on out will be partially colored by this first attempt. Every rookie writer faces this dilemma. We want our names out there. We desperately cling to the idea that when our work hits the shelves, virtual or otherwise, it’s going to set the world on fire and we’ll be celebrity authors extraordinaire.

The realists among us understand how rare it is for that to occur. It’s actually quite difficult to make a living as a writer, even if you’re good at what you do and sell well. Books just don’t pay that much. The digital book revolution isn’t going to change that. Still, we do our due diligence and join writing groups and get all the feedback we can, and when we really think we’re ready… we’re not sure what to do. Say what you will about how unfair the traditional publishing industry can be. Plenty of great talent goes unnoticed, you’re never sure if you’re being paid what is fair, hell – you don’t even always know how many of your books are sold if you’re in print. Meanwhile, Pamela Anderson can “write” a book and it becomes a bestseller. No matter how difficult, at times insulting, unfair, and in many ways degrading to the writers the traditional publishing industry can be, it has the gift of telling you when you’re ready to be out there. More often than not, that answer is “oh hell no,” but you have an authoritative answer.

Enter the Kindle, et. al. Now I decide. Is 50000 words a good length for a 99-cent serial fiction? Is it enough to feel meaty, but not so much that I spend years of my life on it and sell it for less than a buck (and only get paid between 35 and 40 cents, depending on where you buy it)? I wrote each of the drafts for TWDY in a month, and I’ve spent about another month editing each. Is one a month a good rate? Can I keep that up when I start editing City of Magi next month? (Answer: no.) Should I have a bigger backlog of issues to keep me on a regular pace for a while?

There are a thousand questions that (should) come with the decision to publish, and none of them is more important than “Is this good enough to publish?” Am I ready to Ship It? We’ll see. I can still tweak; I can still rewrite. Unlike software, though, it’s never good form to publish “patches” for a book. Would you be happy buying a copy of Windows that can never get updated? I know I wouldn’t.

Shelter From the Storm will be out soon. But it’s terrifying to have that decision looming over me. Sooner or later, I have to pull the trigger and Ship It.


Read more