How Fast is Your Turnaround Time? 418
petrus.burdigala writes "I work for a mid-sized commercial software company (~20 Mloc) and we are frequently challenged by our supervisors to get fixes around the clock. Overall, we manage to get a 'bullet-proof' patch in about 4-5 weeks (from coding->QA->Build/Packaging->shipment), which I consider not so bad. But the other day, we got an urgent request from our support team to come up with a decent fix in 48 hours. I think they're a tiny bit unrealistic. So I wanted to get feedback from my peers: are we doing that bad? It takes months for other software vendors to issue zero-day exploit fixes, are our customers being unreasonable?"
Definition (Score:5, Funny)
It may just be me but I think that's why they are called "customers"
Parent is right. (Score:5, Insightful)
Sometimes, customers are unreasonable and if they are, they should be treated with respect and the problem explained to them. Yes, they may be incredulous, but if you hold your ground (if they're being unreasonable), treat them with respect, they will come around.
The fact that the parent was moderated down just shows me that the arrogance, contempt, and stupidity in corporate America is alive and well - especially in IT.
That works both ways. (Score:5, Insightful)
Maybe the developer is being unreasonable.
It isn't possible to determine which from either person's viewpoint. You will ALWAYS think that you're right and that the other person is unreasonable.
Which is why you need criteria for bug escalation. Generating an incorrect response on 1 type of transaction for 1 specific scenario that may pop up once a year is far less important than a bug that corrupts the entire database.
And if your product is considered "mission critical", I would expect a data corruption bug to be fixed within 24 hours. Even if it is nothing more than rolling back the recent patches and re-issuing the previous version.
Re: (Score:2)
Of course, 48 hour turn around may not be possible.. that's another issue.
Re:That works both ways. (Score:5, Interesting)
Then you're going to have a bigger problem! It's the same thing in any kind of relationship, just bowing and scraping and always saying "it's my fault" is going to cause bigger problems in the future than just saying "nope, we're not gonna fix that. or "sure, well fix it, but not now, you'll get your patch when it's tested properly, in the meantime, do this instead"
Re:That works both ways. (Score:4, Insightful)
Now in this case the customer may be being unreasonable with the 48 hrs demand. But it all depends on the issue. There have been times when my company has been able to get out a quick fix within 24 hrs and other times when it has taken 3 weeks. It all depends on what the issue is, and what the solution is. There has to be some kind of middle ground that could have been reached.
Re: (Score:3, Insightful)
I had that conversation with another executive recently.
He dropped off his laptop with "problems". I suspected viruses, spyware, whatever. I was in the middle of other work, so I didn't even fire it up. Later that day, he asked me "How long will it take?" Being that I was on the way to a meeting at that moment, and had all kinds of urgent company tasks to do, and I hadn't inspected the system yet, the answer was "As long as it takes. I don't know." He wanted an answer lik
Re:That works both ways. (Score:4, Insightful)
Bullshit. A corrupted database of inventory of toilet paper can be far less dangerous than the one type of transaction for one specific scenario that may pop up once a year when that one transaction decides the rod position in a nuclear reactor.
In other words, you have to know the importance to the customer.
And, yes, weeks can be way too slow, depending on the nature of the bug. If it means a large customer's ordering system is down until the patch is ready, not fixing it for weeks is likely to lose you the customer and any goodwill with a lot of other companies.
No, you don't need criteria -- they will get in the way of common sense every time.
What you need is rapid impact analysis, and teams that are able to tackle different tempos, based on what others better informed tell them.
Re:That works both ways. (Score:5, Funny)
Re:That works both ways. (Score:5, Funny)
Sometimes I long for the easy days before I got that PhD in Nuclear Science/Tissue Engineering. Before I knew how the nuclear power/toilet paper industry really works.
Re: (Score:3, Funny)
Re:That works both ways. (Score:5, Insightful)
You know what? To the customer, they're all nuclear rods. They don't care about your problems, they care about theirs. And those problems are critical to them.
You wanna know how escalations work, find out how important the customer is to the company. If you can get someone to unreasonably escalate your call because you're a big contract, you can get a lot of attention. If you're a small customer, or, if the vendor has balls, you might have to wait. Because what you're asking for isn't that big of a deal to us.
In my experience, if you can convince a VP this is a show stopper, you can get a lot of screaming -- it's like being in the army that way. If you can't get a VP/VIP on board, you get to stand in line.
Your priority to us is in proportion to related revenues to you.
Unfortunately, a fix can't always be done in the timeframe demanded. Sometimes, you have to push back. Sometimes, you don't get a choice.
Cheers
Re: (Score:3, Insightful)
Oh, you misunderstand me. I'm not an advocate that whoever can scream loud enough should get the fastest service. I'm pointing out in that in a hierarchical organization, someone e
Re: (Score:3, Insightful)
You're not talking about "importance to the customer" but rather "importance to society".
Although a nuclear reactor is kinda important, there is one minor problem with reasoning this way; pretty much everything is more important than toilet paper inventory from society's point of view, so their inventory bug will never be fixed.
Re:That works both ways. (Score:4, Insightful)
In other words, companies need senior staff who both can and will make spot decisions, and not just management following a flowchart based on pre-determined criteria. That only works in a field where there are no surprises, and software development most certainly is not one of them.
Re: (Score:3, Interesting)
4-5 weeks for a maintenance patch is fine, but if this bug is stopping your client from doing their work, you should be getting single fixes out the door much faster than that. Patches need to be prioritized. Go back to your last rev, fix only the problem in question and release that small subset as a hotfix.
IMO unless you're writing an operating system,
Re:That works both ways. (Score:5, Insightful)
Re:Parent is right. (Score:5, Informative)
If a customer buys a support contract that explicitly states that 1 week is a reasonable turnaround time for an issue you'll be amazed to find out how pleased the customer is when you fix a problem in 72 hours. If some asshole salesman tells them that they can expect solutions to any issue in 2 hours, well, get ready to deal with an "unreasonable customer".
I unreasonably expect this post to be modded +5 insightful.
Re:Parent is right. (Score:5, Funny)
Re: (Score:3, Insightful)
I'd add that if you are really good at turning around fixes in 72 hours, the customer will come to expect that. It will get to the point that they'll growl and pester when you take 96 hours on a fix.
Managing the expectations generated by your history of success is much harder to do, regardless of what the SLA says.
Re:Parent is right. (Score:4, Insightful)
Re: (Score:3, Interesting)
The important thing is your customer facing person(for that matter your manager) should be aware that even if he or she thinks the b
Re:Parent is right. (Score:5, Insightful)
In case you are wondering why the floor on the security issue fixes is a little longer, we usually put the initial problem and the fix through extra review so we ensure we truly understand the problem and that the fix solves all likely related issues. Then we have to decide whether to do a patch or a maintenance release. This process adds additional time.
Having said this, it is impossible to know from the description whether the customer is being reasonable or not. I have had issues where I had to come up with a fix within 24 hours and other cases where the demand was unreasonable. Hope this helps.
1) What is the business impact of the bug?
2) What is the data integrity impact of the bug?
Re:Parent is right. (Score:5, Interesting)
The fact that the parent was moderated down just shows me that the arrogance, contempt, and stupidity in corporate America is alive and well - especially in IT.
If you had a single license and no paid support... Well... We might have a general update next month with a public patch. We might not. Have a nice day.
Of course when you sell software as a service then thats how it works.
As a side note, one customers feature request created a completely separate build just for that customer which was annoying to the programmers but since they paid good money for it, they got what they asked for. Although... I remember the programmers eventually including the features for everyone else as a optional package just to avoid that so in the end even the single client customers benefited.
Re:Parent is right. (Score:5, Insightful)
"Sometimes"? Heh... Good one.
and if they are,
"if"? Man, where do you come up with this stuff?
they should be treated with respect
Ahahahaahahhaaaa... Heh...
and the problem explained to them.
HAHAH[choke]
[gasp]
[snort]
Ahem... Please, stop, I can't take anymore.
The fact that the parent was moderated down just shows me that the arrogance, contempt, and stupidity in corporate America is alive and well - especially in IT.
Some people deserve contempt and our scorn.
They act as though we can save the world before dinner when they want something, and call us miserable worthless slacker bastards the next. They insist we fix their problem in 48 hours when they can't even describe the problem accurately enough to reproduce. They need us and beg us for help and resent every second of it. They treat us like disposeable/interchangeable cogs, then bemoan that we each have unique and difficult-to-replace skillsets.
You want to know why geeks look at most people with utter contempt? Because they spit on us first.
Re: (Score:3, Insightful)
Re:Parent is right. (Score:5, Insightful)
Technically true, but irrelevant. If cows went away, we couldn't have any more hamburgers. That doesn't mean we'd all starve to death, because we can eat other things. But you want know the funny part here?
We could do most of their jobs (perhaps with a bit of training). Not all of us, and not all of their jobs, but in general. They cannot, ever, learn our jobs. One of our surprisingly few actual skills, "problem domain reduction" (kudos to 19thNervousBreakdown for the term), most people simply can't learn, regardless of will or even intelligence. On the flip side of that, however, it means we can pretty much accomplish anything we try, from coding to plumbing to animal husbandry to stonemasonry.
Think, really think, about how many geeks you know who, during the tech crash half a decade ago, did just fine on a variety of completely unrelated-to-IT jobs. Personally, I did a stint in construction/carpentry, and produced some damned nice work (if I do say so myself) - with ZERO training beyond casual observation of standard proceedures. I don't say that to brag - Hell, I don't really consider it much to brag about - Just putting myself forward as an example. We can do their jobs. They can't do ours.
No, it's because you act like a self-important little shite who thinks they should be bowing on their knees and sucking your dick for every line of code you produced.
Not really, because I code for me. They just pay me for it. I'd do it in my spare time if I didn't do it as part of my employment. I stay up-to-date on the world of IT because I find it fascinating, not because someone pays me to freshen my skill-set or because the terms of my state-permission-to-practice requires some pathetically low number of hours of study per year.
Anyway, all of the above said, I do try my best to remain humble and polite to most people, geek or not - And for the most part, I succeed. I very much doubt most people who know me would call me a "self-important little shite". But still, the constant jabs come anyway - From "complimenting" me on my skills the same way you would compliment medusa on her hairstyle, to barely-tempered insults only blunted by the fact that we've usurped the language no differently than blacks using the word "nigga". "Dude, you're such a geek!" "Yeah, thanks". People look at us as freaks for what we can do, and you tell us to respect them?
Not Too High! (Score:5, Funny)
Get back to work!
Re:Not Too High! (Score:5, Funny)
Re:Not Too High! (Score:4, Funny)
None (Score:5, Funny)
Small Startup Experience... (Score:5, Insightful)
The Real Meaning of Bad (Score:5, Funny)
Marketing: We need it real bad!
Engineering: How bad do you need it?
Marketing: <puzzled look>
Engineering: Careful what you wish for... OK, Ops. Ship it!
Re:The Real Meaning of Bad (Score:5, Informative)
If they ask for something within 48 hours and expect something usable, it is up to you to educate them.
It's about risk (Score:5, Insightful)
I often explain to the user that I can push changes out immediately, but it introduces certain risks. I then detail the risks they may face, and that if they say to go ahead anyway, at least they'll be aware of what might happen.
Re:Small Startup Experience... (Score:5, Funny)
A common scenerio for me goes like this:
1 - client reports a problem.
2 - spend 2-3 hours on phone with client identifying what's really going on.
3 - spend an hour or so in SQL Profiler/Delphi debugger to find the root cause.
4 - half an hour documenting what the problem is, causes & how to replicate in order to hand it off to a developer in an off-shore office
4 - have my supervisor ask me Monday morning if I can look at it because the client is cranky & the developer is sick/has quit/has family crisis/there is a public holiday in that country.
5 - fix the damn thing which only takes a few hours to code & test & delivery after all the hard work was done in step 3
6 - wonder why the hell I am still with this company
Re: (Score:3, Insightful)
Sit down and detail what you REALLY DO for the company and how valuable you are. Explain that you would like to get a new job title and pay raise commiserate with your responsibilities. If they don't pay or you think they may fire you then start looking for a new job.
Life's too short to not get paid what you're worth. Plus you can retire earlier.
Re:Small Startup Experience... (Score:5, Insightful)
Pfft (Score:2)
Hmmm. (Score:5, Funny)
1 to 2 weeks (Score:5, Informative)
how long is a piece of string (Score:5, Insightful)
If you know enough of the code tree you can tell when first reproducing and examining the failure whether it is a one off mistake or a larger procedural fault.
Single instance stupid errors (doh! moments) can be rectified and put through testing fairly quickly, however if your initial examination uncovered a larger problem then obviously the process will take longer (if at all - consider workarounds).
If the original dev/test team has been replaced over time this becomes a more difficult issue and every bug must go through complete verification simply because the extent or ramifications of the code modification will not be known.
In some instances we have had fixes out of the door the same day an issue was noticed, in others months go by before a final fix is put in place.
ditto, but more Re:how long is a piece of string (Score:3, Insightful)
I'd add, it depends on product, the complexity of the codebase, the extensibility, modularity, readability, and extensibility of the codebase (eg, if it's highly modular it's easier to test a fix that's limited to the module/plugin)
I'd suggest that weeks sounds too long for an in the wild update without a security patch - or published workaround limiting your exposure. (eg, "use this method to restrict the IPs that can access it to trusted ones.") But that isn't m
four or five WEEKS? (Score:4, Interesting)
Exploits should be a high concern for any company
Re: (Score:2)
Re:four or five WEEKS? (Score:5, Funny)
Re:four or five WEEKS? (Score:5, Insightful)
Exploits should be a high concern for any company
Which is exactly why exploit fixes must go through STANDARD QUALITY CONTROL. What the fuck good have you done if by fixing one exploit you introduce ten bugs and two new exploits? I don't care how urgently the customer needs it. I'm not going to give them something I haven't tested. That's insane. If they don't like it they can shop elsewhere.
Depends on the scope (Score:2)
Regards,
Re: (Score:2)
part of the sentence. Is SlashDot deleting some
Maybe CowboyNeal (Score:3, Funny)
We don't do "box" software (Score:5, Interesting)
It is uncommon, but not unheard of to have an 8 hour fix. In cases of customer data vulnerability, legislation has been made such that if we are aware of a problem, we have an automatic injunction against us continuing to do business unless the problem is resolved. So when we have a security flaw, our bank stops working untill it is fixed. So yeah 48 hours would have people fired for sure.
Compliance/security are the only two things that can spark a release with less than 72 hours notice though.
Lack of information (Score:5, Insightful)
Well, we really can't answer that question with knowing how big the problem is. If it's an embarrassing typo on a dialog box, then 48 hours is reasonable. If it's a windows vista security patch, then 48 days would be unrealistic.
-Grey [silverclipboard.com]
Re: (Score:2)
Not to sound like a M$ fanboy or anything, but they're average time to fix is 48 hours. The other 46 days is just how long it takes them to cycle it out. I assume that if you're cooperate or some other important customer it is possible to get the patch faster, but I honestly have no idea.
Re:Lack of information (Score:5, Funny)
It doesn't take 48 days to burn a Linux CD and send it to the client.
Can't compare (Score:5, Insightful)
It depends on what you're maintaining and how complicated it is. I've gotten fixes out in 2 or 3 minutes. That doesn't mean I'm fast and you're slow, though. "How fast is your turnaround?" is like "how long does it take to write a computer program?" It's hopelessly vague.
Re:Can't compare (Score:5, Insightful)
In addition to all of the other comments about the scope of the problem, number of resources, etc, you also have to take into consideration what you're changing. Obviously there are huge differences between patching the avionics system on an airplane vs a banner ad on a website. I've given estimates anywhere from hours to months before. There's no such thing as "X is the right amount of time for a patch" without a lot more details.
One thing you can always do is try and work with the customer to make them aware of the issues. You can tell them that it's possible to get a patch out to them faster, but you will be skipping a lot of the QA in order to do so (depending on what flexibility you have with the standard company process). The risk of it failing would be theirs. If they're OK with that, then you might be able to expedite things. It all depends on what you're patching and how important it is to them.
Re: (Score:3, Funny)
Depends... (Score:2)
The better engineered the project is, the faster development will be. The worse engineered and less centralized, the harder it will be. Also, the larger the size of the project, the more time it will take. Also the size of the company adds extra time as well; smaller shops can fudge on steps to get a fix out but larger shops have
Management strategy (Score:5, Interesting)
Yeah, your turn around time seems good and yes, the customer's request is beyond industry norm.
That might mean one of three things:
One: Customer is being foolishly optimistic.
Two: The entire industry is bad about turn around time, and can, if pushed improve it to 48 hours.
Three: Customer needs it really quick and is hoping to get it quicker by asking. They know 48 hours is well beyond the norm, but are hoping you can do it anyway, because the more time it is unpatched the more they are screwed. They know that if you don't ask, you can't get, so they are at least 'asking'.
Me, I think it is a combination of all three. Customer is being a bit optimistic, the industry is bad about turn around time, and also the customer knows it is a bit optimistic but is making the request anyway in hope you will provide amazingly good service.
Unrealistic (Score:5, Insightful)
So if these people fix speed and available resources, and difficulty is fixed by the task, quality is determined by these factors. Period. There is no arguing with hard, real limits. If they do also want to specify the result quality, then they have to leave speed open. Again, there is no way around that limitation. In fact they should be happy if the team manages the required quality at all in reasonable time. Not all teams do.
Maybe thisn will be an argumentation that is inderstandable for people with a business background. Engineers should already know this.
Software engineering is engineering. Engineering tasks in general have minimal time requirements. Look at structural engineering: Nobody would try to design and build a full-custom bridge in a week. Instead it takes up to a decade, depending on difficulty. And you can generally not speed things up by increasing the team size.
My jaded perspective... (Score:5, Informative)
Overall, we manage to get a 'bullet-proof' patch in about 4-5 weeks (from coding->QA->Build/Packaging->shipment)
Not unreasonable, depending on the size of your release. (How many modules and how many LOC you're changing, the number of change requests or bug reports in the build).
But the other day, we got an urgent request from our support team to come up with a decent fix in 48 hours. I think they're a tiny bit unrealistic.
I think they're smoking crack.
So I wanted to get feedback from my peers: are we doing that bad?
With your regular release schedule, I don't think so.
are our customers being unreasonable?
Yes. That's what they do. If they want a crash development program to get this "patch" out the door that fast, they seriously risk software which does nothing but crash. Really, if they want it that bad, they run the risk of getting it that bad.
You have to ask yourself and your "support team" (sounds more like marketing to me): "Do we wish to ruin a perfectly good reputation for quality and reliability in one hurry-up bashfest followed by weeks of agonizing on-line debugging?" Really, advocate any kind of work-around and risk mitigation response before being pushed into an overly-hasty release that will linger on your reputation like a dead skunk.
20 Minutes (Score:2)
We were on-site at the customer, and we were involved in a shootout to see who would get a major contract.
We were "pre-demoing" to a bigwig, and it turned out we had an incorrect concept of one of the requirements. Hacked out a fix in 20 minutes.
Needless to say, the customer was impressed (as were my bosses
For production level code, though, I'd never do that, but it was a do-or-die sort of thing.
Oh, and we won the shootout (it wasn't even close, according to some of the guys
Difference between Patch and new version (Score:5, Insightful)
Pick 2 of 3 (Score:3, Insightful)
Normally, the smaller the company the more agile. No surprise. They also get patches out faster too. Also no surprise.
When we look at vendors of equal size, the ones who are really quick at sending out patches are in that situation because their software is more buggy, and they have a *lot* of practice. It never fails.
In response to your question, I would suggest that you should look more at the frequency of patches and less at the duration. Sure, it might not be as fast as your support group wants, but if you start reflexivly sending out patches every time someone yells, then your overall product will suffer since you can't possibly do the proper QA to ensure THAT patch you just whipped up doesn't break something else.
That brings me to the age old choice:
Pick 2 of the following:
Speed
Quality
Cost
How much time do you spend on TPS reports? (Score:5, Funny)
The last time I did one I forgot the cover page and my 7 bosses all bugged me about it.
It depends on the issue... (Score:2)
Some things are trivial and fairly obvious mistakes, that are often easy to fix without breaking anything, in which case it's not too hard to get a patch out quickly. Format string problems for instance, shouldn't be too hard to correct.
Often a little extra validation can correct a problem too, just put in a check for a value being zero before doing a division etc. Things like this are also easy to test, and don't break anything else.
Longer turnarounds arise when the issue is more of a de
Extreme Programming (Score:2, Interesting)
48 hours is reasonable (Score:2)
Depends on the team and the bug. (Score:5, Interesting)
We had a better patch later, but the initial emergency patch was VERY fast.
On the other hand, if the initial bug report is "Sometimes the program hangs, no, I don't know when. Maybe every week or two." -- well, that's gonna be hard. Exploits generally have the advantage that an exploit is by nature at least somewhat reproducible, and the hardest part is often getting a reproducer. I've had it take six hours to develop a usable reproducer, and three minutes to develop a patch.
Release time depends hugely on process and procedure. IMHO, an ideal procedure would have some kind of way to get a Temporary Patch out into the field ASAP when there's an exploit.
What kind of patch? (Score:2)
D'oh, it would be helpful to know which kind of patch we are talking about. Is that security? If so, how critical? Is that a theoretical case, or a gaping hole that is a dead giveaway to any script kiddie? Is the problem just annoying or mission-critical? Is that going to be used in a network? As a server service? On which platform? If it is a new feature, does it require re-engineering of the code base, or is it a drop-in feature you can be over with in half an hour?
Most importantly, is your code base wel
It depends... (Score:5, Insightful)
48 hours is tad bit tight. However, I've turned things around in a similar amount of time.
But, the old adage is true: you get what you pay for:
When faced with unreasonable deadlines in the past, I usually voice my opinion once, and just do the best I can. Your higher-ups are probably already quite stressed at this point, and adding stress to the situation doesn't do anything for your career or theirs. Rather, if you make the point that you're doing the impossible, you might just have a little bit more bargaining power when it comes time for raises.
But on the flip side of the coin, if management doesn't learn, and you find yourself constantly asked to do the impossible, you might want to consider employment elsewhere...
Re: (Score:2, Informative)
Most of my cases are resolved by explaining to the customer things that are unclear in the documentation, so it's unusual to decide within 48 hours that the customer is reporting a real bug. Once we agree that they are, then I can usually reproduce the behavior in a day. Once reproduced, then we do not consider 2 to 5 days for a fix to be delivered to be out of line.
Questions I can answer same day. Fixing bugs ta
Pick a policy, follow it. (Score:2)
I blogged about the opposite issue this morning.
http://www.rogue-development.com/blog/2007/11/i-love-my-job.html [rogue-development.com]
Essentially it comes down to choosing a smart policy and sticking with it. If your company's policy is "Spend 2 weeks QA on every relea
Depends (Score:2)
If its a "normal" bug then I think several weeks or months is more the industry standard.
Size of the problem determines response time (Score:2)
That is why I am having trouble giving you a fixed number. I have been involved in fixes done in days and ones that take months. Context.
The real questions is
Does your management know how to prioritize tasks?
Then, do they know how who to put to to each task?
Finally, do they know how to accurately judge if the work is done correctly?
The problem I have always encountered is that a needed fix gets priority at first, then pet projects somehow get in there, and the deadl
What is the weight of water? (Score:3, Insightful)
What kind of software? What classifies an urgent request? Do you make games, and an urgent request means your bug just made front page
I think a better question is, how do you classify bugs? How do you make that trade-off between fixing a bug ASAP and taking the time to make sure the bug fix is done right?
Who is involved in the decision process? Is it just the technical & regulatory folks? Do you pull in business folks to help gage customer impact? Do you pull in sales and support to see if they can push a work around before the final fix is ready?
Those are all better questions than, "How fast do you do this task of unspecified scope."
Nothing is unreasonable (Score:2)
You can have it fast.
You can have it cheap.
You can have it reliable.
If they want it in 48 hours, you should explain what that would cost.
If you want to streamline your process for patch deployment, I highly suggest you apply some six sigma or equivlant business process improvement strategy to it. Asking Slashdot is going to be counter productive. Your application is very different from anyone els
Hot Fixes (Score:2)
In terms of period between each formal release; that will depend, but we try to have complete iterations (release or not) every three weeks. Ideally it should be two week
Depends on your field (Score:2)
Major problems in "cool blog software", for example, aren't really a huge issue. If it takes them a few weeks to be solved, then poor bloggers will be without some magic-pixie-dust feature for a bit.
In the telecomm world, though, customers expect a root cause for a "critical" defect in less than 24 hours (and there's a definition for critical, although I won't get into that here). My company actually writes that into our sup
Two prong approach (Score:4, Informative)
(1) Get the customer up and running again as fast as possible. This is as often as not some sort of workaround that is not pretty, nor is it permanent, but it works. The workaround does get thorough testing (impossible within the time frame) but the customer is aware of this and willing to accept the risks.
(2) Get the customer a proper, version controlled, patch that they can install to fix the problem permanently. This can take weeks, most of that time being testing. If the customer is insistent we will ship them the proper patch before it is fully tested (again, making them aware of the risks) and continue testing so that we can send the customer some warm and fuzzy news later on (or, if we find a problem, another patch).
Make a policy. Stick by it. Make it reasonable. (Score:3, Informative)
Criticals get next attention when show stoppers are out. 48 hours, depending on interdependencies and QA needed to make it work; it's not part of an official stable code tree until later.
Minors are in the next stable branch release; every whatever you can handle.
Nigglies are changed when the stable branch releases.
Don't deviate from your policy, and make sure the sales people KNOW AND UNDERSTAND what this indicates and implies. No exceptions; see above.
a lot of that can be shortened (Score:2)
I also work at a mid-sized company in the enterprise software business. We do a lot of automated testing. For an urgent, customer blocking issue, I could potentially:
1) get really lucky and diagnose the problem instantaneously. Realistically, it will take me at least one hour to properly diagnose any serious bug that escaped our qa process.
2) Make a fix. Assuming this is a fairly trivial fix, this c
the fastest response (Score:2)
I'm surprised nobody has mentioned the fastest responses, which may take essentially zero time. One is: "It isn't a bug.". The other is: "Already fixed. Update your installation."
That's a big "it depends" (Score:4, Interesting)
The usual bug fix cycle depends on complexity, impact, and risk. High risk of breaking things and low impact? Generally gets scheduled for the next release (4ish times per year). Low complexity and risk but medium impact? Code today, regression test the rest of the week, push this weekend. On average, mission critical bugs can get fixed in 8 hours or less around here, small to medium stuff is put on a weekly(ish) cycle with *lots* and *lots* of testing, and large stuff gets rolled to the next major release, unless it just can't wait that long.
What type of product? (Score:2)
46 days (Score:2)
Large product. Billions in sales go through it.
ITQA takes 10 days with no defect- 20 days with a defect.
Scheduling installation time, Sox forms, required paperwork overhead, project approval comprise the rest. Actual coding and testing probably bout 8 to 16 hours.
At a small privately held company, it would take us 1 to 3 days.
People don't know how to buy software/tech (Score:2, Insightful)
The more you give, the more they want (Score:3, Insightful)
Consider this: What would be the managerial response if you asked for a cost of living salary increase and that you needed it within 48 hours? Do you think that they would be willing to work day and night to make that happen?
Working in panic mode is not professional behavior, and it certainly is not conductive to good engineering practices. Furthermore, it is detrimental to long term company survival. Engineers who support continued unreasonable demands have only themselves to blame for enabling poor strategic planning by management.
This reminds me of an "unreasonable" customer (Score:4, Interesting)
So, I saluted and said I'd try really hard for 3 weeks for the first version, then about three months longer for a version that would work all the time. Which is what happened.
Do you know the impact on this customer of not having the fix that soon? Maybe it's worth it to them...
Bug fix turnaround time (Score:4, Interesting)
Really, it depends on your environment, and what needs to be done.
I'll use one of my web site as an example. It's all PHP and Perl, so ya, it's programming (I'm sure people will argue this).
Since I wrote all the code, I know it all inside and out. If you say "there's a problem [here]", I know exactly what file to look in, and what code to look for. I've banged out changes, tested them, and put them into production in a matter of minutes.
On a high traffic web site, we had a java applet which was being used by about 25,000 people per day. For little things, I'd change the code, test on all applicable platforms, and roll out the change in a few hours. Even then, the bosses were sometimes displeased with the time it took. Since I was careful to test, I never rolled out bad code, so I was never pushed into the long QA cycles.
Working with one company, things were a lot different. It went something like this.
1) Propose the change to your manager, with supporting documentation.
2) Manager would go to the project coordinator (i.e., customer liaison)
3) project coordinator would go to the customer
4) customer would approve the change.
Up to here was anywhere from an hour to a week. Sometimes the customer would put stipulations on the change, such as "there's a big event happening, or going to happen, don't make the change until X time."
5) document the proposed changes
6) hold a meeting with development, QA, the project coordinator, and management. Discuss the potential
changes.
1-3 days later
7) hold another meeting with the same people to rehash the changes.
1-3 days later
8) hold another meeting with the same people to rehash the changes.
9) Write the changes. Make them available to the QA team.
3-7 days later
10) Explain to the QA team that the errors they are experiencing with the fix have nothing to do with the fix, they were preexisting problems with another piece of code.
1-7 days later
11) hold another meeting with development, QA, project coordinator, and management, to explain that the error has been fixed with the supplied changes. The other problems are elsewhere.
1-3 days later
12) hold a strategy meeting to plan on how to fix the other problems.
13) fix the other problems, and break more things.
1-3 days later
14) have QA test the other changes.
14) roll back changes in step 13
15) beta test the previous changes, and notify customer
16) Customer balks at other pre-existing problems.
17) Repeat steps 5 to 15 again, until the customer gets tired of balking.
18) Implement changes.
Then start the process all over with step 1 to fix the other pre-existing problems.
The solution really is...
1) Identify the problem.
2) Gather together the appropriate staff who won't talk outside of your group.
3) Fix, internally test, and implement the resolution.
4) If anyone asks, there was no problem to start with, and you were all really working on steps 5 to 15 of the previous plan on another problem.
Funny how that works.
But, it's a matter of, is it a trivial fix, or something that requires serious rewriting? Did someone miss trapping invalid input in one line, or is it a poor coding practice through all of the code? Is it an included library that simply needs to be upgraded and recompiled?
Re: (Score:2)
Re:Web based (Score:5, Insightful)
It's bad enough that they directly state they're not really testing patches with a 15 minute turnaround, but the fact that they're making mistakes that can be fixed in 15 minutes speaks loudly as well.
Re: (Score:3, Interesting)
Sometimes (just sometimes) it's obvious what the bug is, and it's obvious that testing is meaningless. Would you want to hire a company which does meaningless things to please you?
Re:Web based (Score:5, Insightful)
1)Works
2)Works correctly for all corner cases
3)Does not have unintended side effects
4)Didn't accidently include some other changes you were working on before, which are not ready for production.
You still need to QA. Attitudes like yours are why the quality of software is so poor.
Re: (Score:2)
In this day and age, quite often it's the company that can respond quickest who gets the business. You can't afford a three week integration testing period whilst fifty trucks per hour show up at a gate waiting to be processed.
Good on you for responding to your customers.
Turnaround time (Score:5, Interesting)
We generally get fixes for real bugs out within 24 hours, unless the problem is traceable to the OS, the only factor really out of our immediate control. Even then, we do a quick evaluation to see if we can replace the OS function. Over the years, we've replaced quite a few of them, but rarely within 24 hours.
But we know our code backwards and forwards; I wrote the majority of the current codebase myself, and I can generally get to within a few lines of the problem just by a bug's description... the rest is a matter of minutes and testing. This app is very large - comparable to Photoshop in terms of feature count - but it is also very stable after 15 years of whack-a-bug and a continuous drive to make the internal structure as orderly and regular as possible.
It is my observation that the more programmers you have involved, the slower your turnaround time (for everything from bugs to features) will be. Likewise the larger the entity, the slower it will generally move. Almost every layer of management and corporate compartmenting disease will contribute to slowing down the process.
For the apps that I use that I have had the experience of reporting bugs, it is my general experience that bugs often are never fixed at all. One browser, "Omniweb", truly my favorite in terms of features, has bugs that make it essentially unusable for me. Crashing, slowing, lockups and so on - really serious problems. I've reported them, they never were fixed, in fact the software was never updated. Eventually, I just went back to firefox. Then as Leopard came out, after years of doing nothing, they released a "Leopard version" in which, perhaps, I might find those bugfixes if I looked... but as I say, I have moved on and no longer have any enthusiasm for the product. Slow bug repair (or ignoring them) is synonymous with telling your customers you really don't care what kind of experience they have with your software.
Apple, with all their emphasis on customer experience, does this too. They've had bugs in hand for very long periods where they simply don't address them. If your bug isn't something they think will affect a lot of people, it isn't likely to be fixed. I've not yet purchased Leopard, preferring not to catch early-adopter syndrome bugs myself, but when I do, I would not be the least bit surprised to find you still can't refresh a remote share that's been changed by the remote OS; that the wifi differs hugely in compatibility between PPC and Intel hardware; that mail still hoses the sent mail box based on the return address; that shell fonts are poorly rendered; that shell ANSI compatibility is still broken; that the OS still provides locked-up beachballs at the most inconvenient moments; that the OS still puts the wrong things away on the HD when RAM gets tight, and consequently becomes massively unresponsive... Basically, Apple doesn't have good control of their OS, are unable to respond to bugs in a timely fashion, so much so that they triage out bugs based on report counts, and the common patter is that Apple provides a great customer experience. So while my own experience is that bug fixes are important and can be quick in turnaround, here's Apple showing us that you can make a complete thrash out of the entire bugfix issue and still come out smelling like roses. So is a few weeks too long? Probably not, if you have a good marketing department. :-)
Re: (Score:3, Insightful)
Re: (Score:3, Interesting)
Re: (Score:3, Informative)
We generally get fixes for real bugs out within 24 hours
We do too, although we release every two weeks, so it would have to be a critical security bug to get us to do a patch release and not just include the fix in the next code drop. Genuine defects (as opposed to platform support issues, production support issues, configuration problems, or changed requirements) are a stop-the-line issue.
Um, and if it's taking you a month to fix a problem, what is your level of automated test coverage? You are doing
Re:SLASHDOT SUX0RZ (Score:4, Insightful)
IS THERE ANY WAY TO BAN THIS ASSHOLE!!!! (pardon the little pun I threw in)
Goatse was funny 10 years ago but its really stale.