Last minute bugs

Question

Can you suggest tips on dealing with last minute bugs when the product shipping date is very near?

Answer 1

Ship it today, then tell users it was April Fool's prank

Answer 2

Get buy-in from stakeholders on bug priorities. Good communication is the first step in avoiding disaster.

Answer 3

Document the bugs and make sure there is a known issues document. Be as candid as possible with the users and work out a way to get fixes into the next release. If necessary be ready to provide additional support to end users. They will appreciate the fact that you understand the impact of the bugs.

Answer 4

It depends on the severity of the bug, risk/complexity of the fix, availability of testing resources, and product management priorities. i.e. if it ships tomorrow and the fix takes 2 hrs for dev, but 2 weeks for testing, then you can't squeeze it in. If there's a decent work-around, or it affects a relatively low number of users, then product management may decide to ship it anyway. That decision is usually made at the higher pay grades. Your job is to tell them what their options are, and your assessment of the cost/risk/impact of each option.

When enumerating the options for possible fixes and work-arounds, include the bad ones as well as the good ones. It makes you seem thorough, and it makes the mediocre solutions seem better, in contrast.

We're currently in the midst of one of these. A bug was found this week that is pretty much a show-stopper, and it made it though testing because it's only evident when testing against the actual production environment (involves certificates that are only required by the production firewall). They're making time to ram it through testing, but only after we exhausted all work-arounds. I presented the options to product mgt after first asking here on SO to be sure that I wasn't missing an easy fix (wasn't). I was very open about what the fix involved, explaining things in non-technical terms. And we promised to do a formal code review, which further helped calm things down. Then I went and sat with the tester this morning to make sure that she knew exactly what to do in order to test my changes. Now I'll go and knock on her MGR's door and explain that her helpdesk request for admin rights on her PC is REALLY NECESSARY and needs to happen TODAY. Otherwise, she can't delete the certs and re-load... Those are the kinds of things that you do when you've got these last-minute bugs, and the project so far, has been called "best project ever"....

Answer 5

Triage them. Resist the temptation to fix them at the last minute -- you may introduce a worse bug. Only hold up the release for something more serious.

Answer 6

get incriminating pictures of the stakeholders and then blackmail them in to agreeing to your release date.

Answer 7

How serious are the bugs? You know you're shipping buggy software, because you know there are bugs you haven't found yet. If there's no showstoppers, document the bugs and ship anyway.

Answer 8

If your QA team is still finding P1 problems the worst response I could think of is to fix them quickly before the shipping date without pushing the release.

If instead problems are minor the worst response I could think of is to fix them quickly before the shipping date. They should be queued into your regular maintenance cycle.

There is sometimes temptation to run around like a rabbid chicken with its head cut off. Doing so more often than not results in piss poor outcomes.

Answer 9

OK show stopper bugs first:

Let the managers and sales guys know as soon as possible that you have a show-stopper and that the date might be delayed. Have them communicate to the customer (you may have to push hard for this, they hate telling bad news). Remind them the customer will be happier to get the product a week late than get the product not working correctly. Point out how serious the bug is to the operation of the program. Be sure they understand why it's a show stopper in terms non-programmers can understand. Be prepared to explain why you didn't catch it earlier. This is where the team lead needs to be strong and stand firm against shipping with a show stopper. They will forget readily that you missed the date but will never forget that the application did not work. Company reputation and future business depends on delaying, make sure senior management understands this.

Minor bugs - you can ship with these as long as you track them and fix them as soon as possible. Shipping with known bugs and then failing to fix them in the first upgrade release, not good.

Really minor bugs (to a programmer) but which are noticable to the user, fix if possible. The code may work great but if the screen has things that are misspelled or uses the wrong name for something the user is familiar with, the user will think it is a buggy product. I remember reading in Augustine's Law's that dirty pull down trays on an airplane make customers worry about whether the engine maintenance is done.

Answer 10

Here's a story I read somewhere...

When the shipping date arrives and you aren't quite ready yet, burn a really large file onto a CD and change the file extension, effectively "corrupting" the data. Mail this CD to the customer, all the while continuing to work on said bugs. Once they receive it and determine it doesn't work, explain to them that the post office must have x-rayed the disc and corrupted the data. Take a few more days fixing your bugs and ship them a working copy with "DO NOT X-RAY" written on the envelope.

Answer 11

Just state when ask - its an undocumented feature.

Answer 12

Rank the bugs as one of the following

• Critical
• Important
• Cosmetic

Estimate how long it is going to take to fix the bugs in the first two categories. These are the ones that will drive your customers away. Move your ship date if you cant fix these. People are used to software release dates slipping.

Release a beta version or release candidate on the original ship date so customers can start playing with the software without expecting everything to work.

Set a realistic new shipping date. Try to delay the ship date once, or as few times as possible.