How Fast is Your Turnaround Time?

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?"

Comments

Definition

[ShawnCplus]

aren't our customers being unreasonable
It may just be me but I think that's why they are called "customers"

Not Too High!

[Hanging By A Thread]

How much of that 48 hour deadline did you waste reading /.

Get back to work!

Re:Not Too High!

[Fred_A]

I don't know about you but my turnover time can be pretty fast especially if customers call me in the middle of the night. I'll even put my pillow on my head for free.

Re:Not Too High!

[dintech]

Anyway, why are you asking Slashdot? Should you maybe be writing code right now?

Small Startup Experience...

[Black-Man]

You have to serve the client who is paying the bills - and we had a very vocal one (Nik*). We had a running joke about the release d'jour. But it wasn't a joke. We literally would push a new build to them every day which contained minor bug fixes. It was maddening! But no one had the balls to stand up to the 800lb gorilla, so the madness continued. As a side-note, they were acting as a beta tester and anyone in the software business knows what that can mean.

Re:Small Startup Experience...

[Anonymous Coward]

I work in a small company doing support (amongst other things). I've been there longer than most of the developers due to high staff turn over.

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

... wait a week or so for the client to get really cranky ...

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:Small Startup Experience...

[jdjbuffalo]

You can get a better job out of that most of the time.

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...

[PitaBred]

Consider that week or so of waiting as a chance to learn a bit about business politics, your company's political hierarchy and start getting things changed. If they don't change, leave. You're the only reason they're staying afloat, if everything technical eventually falls back to you.

Hmmm.

[Stanistani]

What was that exploit again?

1 to 2 weeks

[duplicate-nickname]

For high priority bug fixes, it usually takes 1 to 2 weeks to get a patch out once we determine that a patch is needed.

how long is a piece of string

[LiquidCoooled]

It depends upon the nature of the problem and the competency of the developers.
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.

four or five WEEKS?

[tannhaus]

I can understand a week, but honestly...if you're leaving your customers vulnerable for over a month, they might start looking elsewhere

Exploits should be a high concern for any company

Re:four or five WEEKS?

[Tozog]

In that case, 5 weeks is not enough time for a marketing team to decide on a new name.

Re:four or five WEEKS?

[pclminion]

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.

We don't do "box" software

[netsavior]

I work for a bank so we don't do box software, but our patches have to meet FTC standards and Federal bank standards.

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

[Wellington Grey]

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.

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

Re:Lack of information

[techno-vampire]

If it's a windows vista security patch, then 48 days would be unrealistic.

It doesn't take 48 days to burn a Linux CD and send it to the client.

Can't compare

[Sloppy]

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

[Shagg]

Exactly... "How long is a piece of string"?

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.

Management strategy

[gurps_npc]

There is a management strategy that basically says aim for the stars.

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.

Parent is right.

[iknownuttin]

It may just be me but I think that's why they are called "customers"

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.

Re:Parent is right.

[jomama717]

The most valuable skill I learned during my short time as a field consultant was how to "manage expectations" (pardon the bullshit bingo term). It's not the customer that is being unreasonable, it is that they have somehow adopted unreasonable expectations of what you can provide them. In other words, it's all your company's fault.

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.

[einhverfr]

For security issues we usually have a 48-hr to 1-month turn around time. I think a turnaround time for urgent issues of more than a month is excessive. Minor issues get fixed based on a number of factors and the turnaround time varies from 24 hours to 3 months.

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.

[vertinox]

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. I wouldn't say its not contempt but you get what you pay for. I once worked for a small software company who would push out emergency patches (even if the issue was minor) within 24 hours if you had the $10,000 package including paid support. No questions asked. Heck, we'll fly one of our reps out there to install the patch himself.

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.

[TheThiefMaster]

I unreasonably expect this post to be modded +5 insightful. Which is of course why you got +5 Informative.

Re:Parent is right.

[pla]

Sometimes, customers are unreasonable

"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:Parent is right.

[einhverfr]

Now, there *are* unreasonable customers out there, but I agree with you. Most of the time it is an issue of expectations.

Re:Parent is right.

[chathan]

We used to have 2 weeks turn around time for critical fixes. So it is always better to inform the customer that 2 weeks is the time they can expect the fix even if the bug is way above critical status. But there were issues which make few features unusable for the customers and we know that they are heavily dependent on these features.We try to fix it in a week or 3 days time.

The important thing is your customer facing person(for that matter your manager) should be aware that even if he or she thinks the bug is trivial and can be fixed in an hour always stick to the 2 weeks target. You can use the same bug as the reason why you don't want to rush the fix early. Tell the customer that you are not happy with the fact that your development process introduced this bug and don't want to repeat the same in the bug fix also and promise to deliver a high quality fix in two weeks time.

In my experience most of the customers are happy to know that the problem will not be repeated than the fix for current problem because they might already have found a workaround to move their business forward. Obviously they cannot stop all the business and wait for your fix.

By the way I was working in a company offering SaS and the customers daily business was dependent on the product. The customers used to have high expectation on the turn around time.

Re:Parent is right.

[pla]

You need to respect your customers, because if they went away, you'd be out of a job, it's that simple.

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?

Unrealistic

[gweihir]

With a little simplification, you have four parameters: Difficulty, quality, speed and available resources. Whenever you fix three, the fourth follows (with some unvertainity). It is well known, that there is a limit on how much you can improve the speed with more resources. So there is an upper limit on speed already. The second problem that difficulty is unknown when starting such a task. There is no fix for that.

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...

[idontgno]

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.

Difference between Patch and new version

[techpawn]

A patch (IMHO) is a bug fit to existing code. Given the resources we should be able to get a PATCH out in a week. However, if you need a new version of the software to address the issue. Then we're talking longer development/testing/QA times if which case 4-5 weeks would not be unreasonable. Bugs should be fixed as soon as they are spotted. If their is need for a whole rewrite then you may want to talk to your staff

Pick 2 of 3

[CambodiaSam]

I know I'm going to end up baiting some developers, but I work for a specialized ASP and see a ton of third party software from a perspective few get...

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?

[Joe The Dragon]

How much time do you spend on TPS reports?

The last time I did one I forgot the cover page and my 7 bosses all bugged me about it.

Depends on the team and the bug.

[seebs]

At BSDi, the initial patch (which did have flaws, but it fixed the problem) for the f00f bug was same-day, I believe; might have been next-day, depending on where you're counting from. (Contrary to popular belief, this didn't violate any NDAs.) Now, that was an emergency patch -- it took a while to come up with a patch that fixed the bug without noticable ill side-effects.

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.

It depends...

[gillbates]

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:

• Granted, 48 hours is tight, but possible if you know the root cause, *and* the customer is willing to forego the usual QA process before delivery. It doesn't mean that you don't do QA, but rather, that you do it later and patch the patch, if necessary. In most corporations, this means that if the customer doesn't complain, QA doesn't get done for these "extra-special" releases.
• Four to five weeks for 20Mloc is probably about average. As a general rule, a good team will average about 1 week per department the fix has to go through: field team -> engineering (fix) -> department review -> QA review -> ship. However, in some organizations, particularly the smaller ones, defects can get turned around in 1 to 2 weeks, especially if the customer works directly with the engineer/developer, and the developer is authorized to make releases to the customer. Be aware that your customers may have dealt with such organizations in the past.
• 20Mloc is not really that big, provided that the project and code was well-organized from the beginning and the original developers are still on staff. But, if this is not the case, or you have a large developer base, where no one is actually an expert on the systems, or subsystems, you can add about a 50% overhead to your turnaround time. If the original developers are no longer there, add 100%.
• If you don't know the root cause of the problem, you can't promise anything, and you need to inform the customer of this - you simply can't make any guarantees because you don't know the scope of the problem. Once the root cause has been identified, a 48 hour deadline is still tight, but is long enough to allow the key developer to build and do some rudimentary testing of the fix. Should the customer choose to accept it at this point (and you *must* make the point that it is their choice), they must be willing to forego the normal QA process, and should sign a statement of understanding to that effect.

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:Web based

[Gregb05]

*15 minutes.
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.

The Real Meaning of Bad

[soloport]

Our running joke used to be:
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

[clsours]

If they ask for something within 48 hours and know what that means, then they deserve what they get.
If they ask for something within 48 hours and expect something usable, it is up to you to educate them.

Two prong approach

[khendron]

I've had situations with customers who require a fix as soon as possible, because if the system is down they are losing money. When this situation occurs, we have two goals in mind:

(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).

None

[EmbeddedJanitor]

I made them believe it was a hardware problem!

That works both ways.

[khasim]

Maybe the customer is being unreasonable.

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:That works both ways.

[Laglorden]

The problem is when the customer is being unreasonable, the "support" (or more likely sales) just agrees to everything they say and "sure, we'll fix it" because they don't a) know any better b) they wan't to sell, not take the conflict c) they're stupid and just passes this backward "fix this, NOW!"

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.

[arth1]

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.

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.

[Anonymous Coward]

The battle between sales and support has raged for years. Forget sunni v. shite, red v. blue, Kobe v. Shaq. Sales v. support is the ultimate battle. Sales tells the customer what they want to hear. Support tells the customer the truth. I've worked both sides of the aisle. As a sales rep I try to be honest about what I'm selling. The software I sell does not support P2P. We don't support it. Need a server. I let the customer know. Some of the other reps kind of gloss over it really fast just to make the sale. Then the customer calls back to support upset. I'd rather avoid that by being honest up front.

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:That works both ways.

[Fulcrum of Evil]

You sell toilet paper and control reactors with the same machine?

Re:That works both ways.

[AdamWeeden]

Which reminds me of the old business adage that far too many businesses and customers forget these days. "It is only a good deal when both sides think so."

Re:That works both ways.

[Jesus_666]

You have no idea how the real world works.

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:That works both ways.

[arth1]

A criterion is something that you can pre-determine. Which is exactly what you must not do here -- a human making a rational decision based on both objective and subjective needs is what is needed. Else, your criteria are going to be either overly narrow and thus useless, or overly narrow and thus worse than useless, when an unanticipated situation occurs.

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:That works both ways.

[gstoddart]

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.

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. :-P That's how corporations work.

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. :-P

Cheers

That's a big "it depends"

[QuasiEvil]

I'm an embedded developer, and when my stuff goes wrong, it can *really* do bad stuff. I've literally pushed fixed firmware to a controller running in a production scan/sort environment within five minutes of finding the bug, because it threatened to completely bring down a huge sort operation (and by huge, I mean 1 million+ pieces that day alone). I've also stayed up all night tracking down a bug crashing a device used by one of our larger (hundreds of millions of dollars per year) customers. Those, though, are the exception, and are driven by the massive financial and PR consequences of not getting it done right now. Throw caution to the wind, code and load if you are reasonable sure what's wrong and the stakes of not fixing it are high enough.

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.

Turnaround time

[fyngyrz]

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:Turnaround time

[homey of my owney]

Yeah, but everything is relative. If you're fixing a Hello World application and you can't get it turned around in 5 minutes there's a problem. But if you're fixing an international banking application bug with security implications, 48 hours is definitely unreasonable.

Re:Turnaround time

[Cacadril]

I used to work for a company that made computers with a version of Unix on them. We would mostly manage to get a fix out in a week, but I managed to reduce that to about two days, in seldom cases one day. I was much of the bottleneck - I did the quality assurance and the packaging. This was in the early 90s. I improved the process by creating something that resembles (remotely) a redhat package system, that made it a snap to revert patches if anything went wrong. The effect was, not foreseen by me, to streamline the process so that we could focus much more on the contents of the fix. I saw in the beginning that also the packaging process could introduce errors and mistakes. Packetizing also helped testing, making it easier to install versions of the software, or just patches, test it, and then revert the configuration to what was needed for that computer's ordinary mission.

The more you give, the more they want

[SystemFault]

From nearly forty years of programming (yes, since the IBM 026 keypunch days), I can tell you with absolute certainty that the more that you do for management, the more that they will want from you. It is not your responsibility to bear all the punishment for the lack of foresight and resource allocation on their part.

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.

Re:Web based

[AuMatar]

Even if the bug is obvious, it doesn't mean that your fix

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.

This reminds me of an "unreasonable" customer

[PatMcGee]

The customer described a program they wanted (to run on an embedded system). I estimated 3-4 months. They asked for 30 days or less. I explained what they'd get if I banged it out that fast - something that would work most of the time and not lose too much data. They then explained that the program would save them over $1,000,000 a month. If it quit working, they quit saving money, but nothing else bad would happen.

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...

It's about risk

[PIPBoy3000]

I work for a large healthcare organization and typically have very fast turn-around times (bugs often get squished within an hour). For clinical applications and other core applications, though, we're much more methodical and careful.

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.

Bug fix turnaround time

[JWSmythe]

    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:SLASHDOT SUX0RZ

[renegadesx]

At the risk of getting modded "offtopic" I will say what everyone is thinking and take a hit for the team


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.