How fast can you get a fixed bug into production?

Question

I'm working with 2 very different applications.

App #1 is a web app where I have direct access to the FTP, so fixing bugs is pretty easy. Cat A bugs are usually fixed within the next day. No problems here.

App #2 is an oil business document control app, where we have to go through two acceptancy test phases - end users test and system test. Any bugs discovered after this phase will retain until the next version, usually 2-3 months. Every new release package is a huge cost. It's really hard to explain to the end users that they have to live with some of the bugs until the next version.

How do you relate to critical bugs that can't be fixed immediately?

Answer 1

The speed which management allows you to fix a bug is directly related to the cost management will endure until the bug is fixed.

I'm a 1-man team. Nothing stands between me and my bugs :)

Answer 2

The faster I fix bugs the more bugs I find I need to fix.

Answer 3

In my personal opinion in your described situation is a very deep structural problem and it should have been dealt with before the project has started. Every programmer should know at least one person to directly push changes if needed and the procedure for this must be clear. Honestly what about security or database problems with potential data loss? I mean of course, if you can't fix it directly inform the staff and tell them to "please don't do this", but honestly the best way is to get this problem out of the world asap. I had a similar case in a terminal application where a program simply quit working after a button was pressed twice. The fix was trivial, but no one was allowed to fix it and it literally cost hours for all the people depending on this thing to run. Demand a shortcut for important changes!

Answer 4

The answer would be a ratio of how much access one has to the production environment to the quantity of lives or money at stake.

Answer 5

Workarounds.

I've had previous experience where a user deemed a functionality dead due to a bug, notified us, waited til the bug was fixed, then told us that during the downtime on that section that they've been entering information into their old excel version of the application (Oracle APEX migration from Excel) and then nicely asked us the turn around time on us dynamically inserting the data from their excel application again. The turn around for that was longer than the downtime for the original bug.

Answer 6

It really depends on a combination of the organisation size, system size, importance of the system & impact of the bug eg:

One Man Shop or Low Impact System (quickest - App#1 above)

Time to fix bug = time to find bug + time to code fix + time to deploy to production

Large Organisation or Important System (longest - App#2 above)

Time to fix bug = time to find bug + time to document & prioritise bug + time to estimate cost + time to approve work on fix + time to design fix + time to document fix + time to code fix + time to document test plan + time to test fix + time to regression test + time to performance/load test + time to schedule & approve deployment + time to deploy fix

Edit: How many Microsoft employees does it take to change a lightbulb? is an interesting read on the topic.

[1]: See http://blogs.msdn.com/ericlippert/archive/2003/10/28/53298.aspx