So, the blog tour planning is going PHENOMENALLY, but there’s one hitch that’s got me a little worried: book bugs.
Okay, I might have just made that term up, but this is what happens when a software engineer transitions into an author! As some of you may know, before I decided to pursue writing full time, I worked at Microsoft for three years. More specifically, I was a Program Manager, which basically meant that I did a variety of things including designing and documenting feature behavior, managing the project schedule, occasionally prototyping features, running beta programs and interacting with customers to get their feedback, that sort of thing.
As the release cycle progressed towards “ship it” (the day we launched the product out into the world), one aspect of my job that became more and more important was triage. “What’s triage?” you may ask. “Isn’t that what happens in war when the field medical staff need to decide which patients to treat and which to let die?” Why yes, it is. And in software, this is the term we use to decide which “bugs” (also known as “defects” or “things in the product not working like they’re supposed to”) we’re going to fix and which we’re not. The idea is that, like in war, we have limited time and resources to address the “wounds,” if you will, in the product and there’s no way we can ever fix everything, so we need to decide which issues are most important to treat now and which we’re going to have to let go.
(As an aside, for anyone not familiar with the software world, for some reason there’s a lot of borrowing of intense/violent terms. For example, “scrum” is what we call a daily 15-min team meeting where everyone gives a status report, or “war room” is what the meeting where the triage decisions are made is often called. I have no idea where this came from, but my best guess is that it’s a guy thing – software is still a male-dominated world, and I guess with all that testosterone floating around everyone feels the need to be macho even though they’re hunched over a computer drinking Mountain Dew all day. As a former rugby player, I can promise you that an actual scrum is FAR more painful than a 15 min status meeting, mmkay?)
So anyway, back to triage. In order to triage, you have to prioritize, which is something I’m actually quite good at. Working with my development and test leads, we would establish a scale to rate bugs from Pri-0 to Pri-3 or -4, where P0 bugs were absolutely MUST FIX (for example, if you click a certain prominent button, the program will crash) and as you went down the scale the bugs became less serious (e.g., a P3 might be something like a misspelled word which most people wouldn’t notice, or a P4 is a nice-to-have like this-button-was-supposed-to-be-a-different-color-and-we-forgot-to-change-it, but it really doesn’t make a difference to the functionality of the product).
The problem with this clever prioritization system was that it meant that sometimes things DIDN’T get fixed, if we were getting close to release and they weren’t important enough. You see, there is inherent risk anytime you touch the code – no matter how careful you are, you just might slip one key on your keyboard and break the entire thing, or worse, introduce an insidiously hidden new bug without even realizing it. For that reason, the closer we got to release, the more strict we became with what would constitute a valid reason for changing the code, and a lot of bugs ended up getting punted (i.e., put off until the beginning of next release) as a result.
Being a perfectionist, this drove me nuts. B/c of course I wanted the damn thing to be perfect before we released it to 70 million people! (Or whatever – Microsoft sells a lot of software, don’t ask me how much.) But you can’t fix every bug. You just can’t. And the thought of shipping a product that I know there are issues in just makes me want to scratch my eyes out.
And so these two parts of myself – the good prioritizer and the vehement perfectionist – were constantly at war inside myself during triage. Throw in a little willingness to take risks (i.e., in being willing to risk the possibility of a bug in order to fix a known one) – which I also have in abundance – and you can see how this was a relentless internal struggle.
The good thing, though, was that I always had talented dev/test leads and managers around me to temper my perfection-seeking, risk-taking tendencies, and so in the end, prudence always won out. Actually, as far as I can remember, I don’t think we ever did manage to introduce any major bugs close to release. I worked with very disciplined, smart people. Good job guys.
B/c now that I am doing this on my own – with the “bugs” in my book – it’s quite apparent what happens when I am left to my own devices… I break EVERY RULE in the book! In fact, with Stitch I found myself fixing P4 bugs (like changing a “she had” to a “she’d” even though probably no one else who reads the book would EVER notice that it made the sentence flow better) LITERALLY 2 HOURS BEFORE RELEASE. This is very bad. Very, very bad. BAD SAM! BAD!
But even though I knew as I was doing it that I shouldn’t, I just couldn’t help myself. And unfortunately, Gio (my cat) while fantastic at many things – like sleeping and begging for food and generally being adorable and sweet – is terrible at watching what I am doing on my computer and making sure I’m not doing anything stupid, considering that he can’t read all that well (yet!).
So now that the blog tour is all set, and my book has been shipped out to 50+ people who hold in their hands the ability to influence the opinions of potentially THOUSANDS of other people, I’m just praying to God that I didn’t F anything up. So we’ll see how it goes.
The good news, though, is that since I’m self-published and my book is distributed electronically and as print-on-demand, at least if I DO find anything, I can fix it up real quick and re-publish, and within 48 hours anyone new who gets the book will no longer have that bug. In fact, I did find one issue in my e-book version about 24 hours after publishing (which I was relieved to find had at least been there since WELL before my undisciplined last-minute editing), so I fixed it up and was able to easily re-publish. But that still means that there are a handful of people out there with an end-quote missing at the close of their dialog, and that knowledge eats at my soul.
So here’s hoping that I don’t find any more typos or missing words or obscure grammatical errors! Because you know if I do, I’m going to have a hard time leaving them alone…