Management When done is done.

Heinous

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.

5 Responses

  1. John Whitlock 21 years ago

    I’m in the aircraft simulation business, and we have a similar scheme (except we call bugs DRs, or defect reports). In our world, every bug needs to be fixed by the end of the contract. However, we have assigned levels to bugs. Level A’s have a negative impact on training – you can’t train a pilot on a simulator with an A-level DR. A DRs range from program crashes to routine things that just ain’t right. You can’t ship out of in-plant acceptance with open A DRs. B DRs are bad, but can be fixed 30 days after final acceptance (and start of training). C DRs are usually cosmetic – documentation and such – that can wait 90 days after acceptance.

    The key is, a lot of shit gets written as A DRs at the start of in-plant acceptance. This is appropriate – you have a few weeks to fix it, and the programmer should decide what is a priority and what isn’t. As the ship date approaches, you start having conversations about whether a DR is an A or really a B. In other words, is it heinous or not?

    Of course, we’re lucky – we have a first acceptance date, in-plant, then a second one, just before training starts, so we always have weeks to fix the worst problems while the hardware is shipping across the country. We also have direct access to the customer, who can help tell us what his priority is out of the DRs. Still, triage is the most important part of late bug fixing.

  2. Tyler Carter 21 years ago

    What the fuck? I’m so confused by this all.

  3. I’m a completionists, so for me heinous shouldn’t exist in late stage bug fixing, if you need it that late in the game, you screwed up big time along the way. If some features still create heinous issue at that stage, it’s yanked and will wait for a next version.

    But then again, rands will say I live in a fantasy world. But in reality, I am just really good at forecasting a correct timeframe depending on my skill and the rest of the team. Normally I already have a working prototype before the budget even get approved, but you know I am just maniac like that.

    From my point of view, we all strive to be completionists, incrementalists are just second rate achievers, one step up from total failure.

  4. Wow, just came across this 2 years later…

    HELL YES.

    Though my phrase is Ship It!!, shouted repeatedly until, well, we ship it.

    Basically, unless it’s going to cause flaming death or data corruption, you can always fix it tomorrow.

  5. Hayden Clark 17 years ago

    Ugh. Ever tried to fix a cosmetic bug in ROM? Kinda hard – especially if it’s in about 100,000 ROMs, in boxes in various retailers around the world. The definition of “heinous” is actually pretty low, as there is NO WAY you can patch it afterwards (or the penalty clause in the delivery contract will wipe out the company).