You and your software development team are close. So close. Just a few more bugs and you’re ready to get those bits out there. You can taste it, but… the bugs keep showing up. Five in the morning. Ten in the afternoon. Oh shit, fifteen more during the weekend. Each day… anything more than zero is just bad news.

Not. Shipping. Yet.

One word is going to help you. One word is going to turn the corner from DOING to DONE. That word is Heinous… and Heinous wants to help.

Let’s back up.

To understand the value of a single word, you first need to come to terms with where your brain is at late in the product ship cycle.

You are insane.

It’s true. You are nuts.

I’ll explain, but first we need to be clear about exactly where we’re at in the product cycle. This isn’t the last month of work… this isn’t the last big push. This is the culmination of a huge amount of work done by a handful of people who have been bleeding from the fingertips for the last month.

You and your team, for as long as can you remember, have been living and breathing “the product”. You’ve spent months designing it and months/years developing it, so it’s hard to figure out where you stop and the product begins.

This frame of mind, this intense relationship with a body of code, is not conducive to actually shipping product because you are blinded by your devotion to the product. You want to see your product successful because of what you and your team have sacrificed and OF COURSE you are imminently qualified to fix what ails your product…

Bugs.

The bane of your existence.

You will kill… kill them all because they threaten you and your product.

See? You’re certifiable.

I exaggerate. Your shipping experience may not have been as intense as this, but I assure you if you’ve spent more than six months on a code base that your collective mental panties are in a bunch.

You need Heinous.

Heinous means bad. Really bad. Horrible sky-is-falling bad. Grossly wicked. Jack the Ripper bad. Are you getting this? Good.

Heinous is the word to describe the type of bug you will not ship with. As a responsible parent for your product, you think you will ship with no bad bugs and that’s where you’re loopy. You’re going to ship with tons of bad bugs. More than you’ll be comfortable with. You’re, however, not going to ship with Heinous bugs because these are the bugs which, if found AFTER YOU SHIP, would stop the presses. People would run around the building screaming. Much money would be lost and heads would roll.

I’m not talking crashes… I’m talking massive data loss… horrible operating system hangs… exploding computers. I’m talking Heinous.

Now, you completionists out there are having a hissy fit right now because I’m suggesting that software should ship with bugs and that offends your purist sensibilities. That’s fine. I expect my resident completionists to hold the perfection bar as high as they are physically able, but completionists don’t ship software. Incrementalists do because incrementalists know that better is the enemy of done.

Still, whether you are an incrementalist or completionist, you both need Heinous. Everyone needs a cue to understand that the time of fixing bugs is over and the time of shipping product has begun.

Here’s a hypothetical recreation of a bug triage meeting from my start-up. It’s me (engineering director), VP of Professional Services, Director of Quality, and our Product Manager. We’re going down the list of new bugs which arrived over night… five days until shipping:

Me: “Bug 9744. Moving applicant back to interview state creates garbled text.”

QA: “There’s a workaround, I’m not sweating it.”

ProServ: “There will be training impact, can we get this fixed?”

Me: “It’s about a day of work.”

Product Manager: “This will reflect poorly on us in the press.”

Me: “It’s a day of engineering and a QA slip.”

QA: “We can test it in our current schedule.”

Me: “No you can’t. It’s a significant change… blah blah blah.”

I have just wasted five seconds of your life that you will never get back. Now, multiply this scenario by the other twelve bugs that showed up that night and you’ve got the makings of a nice product slip. Let’s look at the same meeting now enhanced with Heinous:

Me: “Bug 9744: Moving applicant back to interview state creates garbled text. Is this Heinous?”

Them: “No.”

Me: “Bug 9745…”

See? Everyone gets it. Everyone knows that when Heinous is being thrown around, it means WE REALLY REALLY NEED TO SHIP THIS DAMN THING. Maybe it’s a date driven schedule or maybe it’s a strategic ship date. Who knows? You’ve got to get those bits moving.

Some rules around Heinous:

– You must make sure everyone is aware of the definition of Heinous. Not repeating yourself means you are saving time.

– You may slightly alter your definition of Heinous and that’s fine, but use the definition consistently. Don’t tweak it to your own personal agenda — you will lose credibility and no one will listen to you next time around.

– Don’t use Heinous until you need it. There are four or five big freak-outs in any product cycle before Heinous needs to come into play. If you use it early and then non-Heinous bugs start sneaking in, you’ve blown it and devalued Heinous for everyone. Don’t.

Anyone who tells you that developing software is hard is absolutely 100% wrong. The hard part of developing software is actually shipping the product out the door. It’s not designing or coding or testing a product that is tricky, it’s just that everyone on and off the product team has a damned opinion about this or that or how fast or how slow or how it looks or how it feels. Your job until Heinous arrives is to carefully aggregate, listen to, and act on those opinions because, chances are, someone is smarter than you. These opinions will give you a better product.

With Heinous, the discussion is over. The product is done.