Software Management: Avoiding Boss Bugs

So you’re a manager of a team, and you’re building a cool customer experience. You’ve got developers, you’ve got testers, you’re running around balancing schedules and worrying about processes and getting the legal team on board and dealing with deployment issues and watching the bug count and haranguing the team to fix one more thing and then you say it’s done and you ship.

And then you get the mail, and you know what it’s going to say as soon as you see

From:  Boss, Your
Subject: Re: Project Rubik Launched Today!

Sure enough, you open the mail, and Ms. Boss (or Ms. Boss’s Boss) has found a bug. And it’s a stupid bug. It’s a spelling error on the second page, or it’s I clicked the link on the bottom and nothing happened, or it’s I tried in IE6 on my home machine and all the words are jumbled, or it’s I typed “mass” in the body and it was rejected for profanity. And you see this bug, and all you think is I should have caught this, Ms. Boss must think my team has no quality control, and damn it, that’s all anyone is going to remember. Congrats – you’ve snatched defeat from the jaws of victory.

Has this happened to you? It’s happened to me. It probably happened on half of the customer-facing features I launched at Amazon, where Boss was played by my actual boss, or my SVP, or Jeff Bezos, each one of whom was a passionate advocate for the customer’s experience and was going to click through the moment we shipped to take a real look, no matter how many times she had seen it during the planning and testing phases. The WhitePages CEO had the same skills and obsessions. Aaaaggghhh – we should have done better.

The good part is that you really can avoid Boss Bugs, and you’ll be happier if you do so. There are simple and complex things you can do, and I try now to do all of them, and it mostly seems to work.

  • Take a break, then be a user. The hard part is the precedent – take a break. This doesn’t mean just go get coffee – you need to find a way to clear your head of all of the things that you are thinking about related to the project. Do it first thing in the morning, or right after dinner, or after a bike ride. But make yourself do it – go through the whole process. Do it slowly, read the screens, take your time. Your users will not be as fast as you are.
  • Demo to someone you know. Show off your work to someone you trust, in the software business or not – really use the features and look at the pages while you’re doing it. Ask them to drive, too.Both of these first two techniques will also help you find things that you need to check “later” or have someone look at, so have a pen handy.
  • Do a real bug bash, and be part of it. Yes, bug bashes are a pain to schedule, but I’ve never been unhappy that I did it once it was done, and they’re always useful. Make someone else deal with coordination – you should put on your headphones and do your own bash. I try to “win” (find the most bugs) and encourage others to do the same. Great managers are great bug finders. And if you find a lot of bugs? You’re further away than you thought. (Good to know now.)
  • Set your expectations with your QA team clearly. It doesn’t matter if they work for you or for someone else – your QA team is the way you make sure your product is good enough to ship. So make sure they understand what your quality bar is, and that even if you have good specs, you need them to help make sure that the product is great, not just that it matches the specs. The worst product I almost shipped came about because I didn’t make sure that my QA team knew that unfinished sentences on web pages were ship-stoppers, and that there was nobody else who was going to find them. Quality isn’t just that the API or Selenium tests pass – it’s that the product looks and feels right, and if that’s subjective, there you go – if it was easy, we wouldn’t be paid for it.

On balance, having a boss who cares about the customer experience is like having a boss who’s technically competent – it’s great having someone who gets it in your chain. Pretend to be them and you will deliver better software, guaranteed.

If you have other tips to suggest, by all means, please add them to the comments.

(BTW, Boss Bugs don’t just apply to software – they also apply to processes and planning. I had a Boss Bug in my own planning process recently, and my Boss caught it – good for him and good for the project.)

1 Response to “Software Management: Avoiding Boss Bugs”

  1. 1 lee Dec 10th, 2008 at 1:46 am

    Great topic. I’ve been cutting corners in QA just to keep up with release dates. It always comes back to nip you in the behind!!

Leave a Comment

Twitter Updates

[aktt_tweets count="5"]