I know all of you are always interested in all the 'Techno Stuff' I write, so I thought I would try to economize the vast complexity of what goes into repairing a software bug.
Well first, a support representative receives support call that something is wrong from a user, so they ask about 6 hours worth of unrelated questions that have absolutely nothing to do with the software at all before concluding that they need to send the call to the next level of support, by the way were you asked to sign away your 'first born' for this help?
The level two technician takes the call and begins by asking you 'how long have you used our software, are you really sure this isn't related to improper use?' After about 3 hours of convincing them you know what you are talking about, that you have been using the software longer than they have been out of diapers, they finally perform a test and conclude that you are right, something must be wrong, it might be a 'bug.'
In the mean time about 3000 other users have already been on hold for 19-hours attempting to report the same bug, so finally the problem gets pushed along to the the higher ups so that the software fix process can really begin.
Well, they first schedule to have a go-to-conference of 2 people, one here in the US and one in some foreign country (I can't even spell) where programming is at, to organize a meeting of 20 concept engineers, to pick a team of 4, to brainstorm who actually needs to work on the project, and finally picks the lowest guy/gal on the totem pole as the 'repair tech'.
The 'repair tech' then must study the problem for 3 weeks or so, before writing a purchase order to employ a 3rd party contractor to actually 'write the code'. The third-party contractor then must schedule the work in some out-of-the box software scheduling program to see when it is assigned for actual 'coding'; finally the time comes and they write the code (it takes about 5-minutes), and it is then sent it to the 3rd party contractor's Alpha team for 3 weeks of testing.
The third party contractor then sends it back to the software company's ‘repair tech’ who conducts about 10 days of beta tests, and then reports to the ‘team leader’ it is fixed, and the team leader writes a memo to the "engineer in charge" that the fix is ready for release, but the engineer is on vacation for 3 weeks, so the fix is not authorized for release implementation till the original's engineer's replacement takes 2 months to review the project, because the original engineer in charge was notified that he had been moved to a different assignment the day before he got back from vacation.
It is also at this point that all those technical support representatives who are the first line of response are finally getting an initial 'technical support document' on the bug admitting there is a know problem and that it has been referred to programming for repair.
And that's the best information I have as to how 'software bugs' get fixed so quickly.
Murph
PS - I can write this simply 'because I want to', it's my blog and everyone needs a good chuckle now and then.
PSS - if you are one of those outstanding customer techs, software engineers, code writers, etc. please don't take offense (even if you know this is approximately true).
PSSS - I would almost like to put together a PowerPoint of this process and conduct a webinar on resolving the complexities of complex processes, but I would probably need to conduct a study before doing so.