The customer calls the boss.

"We are getting our ZZ-503023423 Model 3 installed next Tuesday. Can you support it because it's important."

Never mind the customer has known for six months the Mod 3 is on its way, drop everything and work day and night to get the thing integrated.

Then they don't actually use the Mod 3 for three months.

''Yup. That's the reality that software developers have to deal with - and why formal methods and researchers often end up missing the point''

Source of much misery and ForcedOvertime.
----
Both your boss and you missed a chance to some great profits.  Your boss's answer should be "Great, we charge $XYZ for special urgent projects." or "No problem, we have overnight surcharge $XYZ for working overnight.".  And you should ask for special compensation for this kind of crunch projects too.  Charging more for urgent projects with short notice is just standard practice in many other industries, e.g. construction, printing press, repair shops, internal decorations, etc.
----

One way to respond to such a customer is merely to make him pay. Not in terms of money, but in terms of features. Do you really want the Model 3 support? We can't have it by next Tuesday; we can have it in three months. And in return, it'll put off by at least three months the next-gen upgrade we've been working on.

Of course, this requires management to have realistic expectations. Often the problem is not the customer, but management.

At one job I had, we used to do this with the marketing department: Yes, you can have the Whizbang feature, but it'll push out product launch by at least a month, and it'll increase the risk that we'll need to push out the schedule further. Or we can save the Whizbang for another release and ship on-time. It's your choice. Frequently, they agreed it wasn't worth the cost in time and risk. In either case, we avoided the DeathMarch. --TimKing

''Of course that implies you have enough power to bargain like that. In practice many developers don't have that power, and have to "just do it"''

Not knowing your circumstances, I can't comment on your particular case.  But in many cases I have seen, "just do it" will simply encourage such requests from your users -- because it works for them.  Even if you have to "do it", do it screaming and kicking all the way through, and make sure they pay for it, either in terms of money, or in other terms.  The easiest will be, "You want Whizbang next month, OK, let's work 3 consecutive overnight together right now to workout and finalize the specification.  We can't start until the specification is signed-off." -- Someone else

''Sure. . . In an ideal world, but specifications are loose, and the user interface you designed according to spec "isn't what they wanted" - leaving no choice but to fix it. Even with agile methods customers may switch things around behind you i.e. "well, we were using an ipaq with bluetooth to a nokia phone, but we decided Wifi was better . . . anyways the software crashes now and we need the fix ASAP or we won't pay" is the reality. ''

Then you just "fix it" screaming and kicking all the way and make them pay again.  "This isn't what you wanted?  OK, let's work together for another 3 consecutive overnight to clarify what exactly is it you want, workout the spec, and sign it off.".  If the client is another company, my boss will just say, "Ok, you don't have to pay, we hereby revoke your license to this software.  And we will send you the documents that belongs to you (i.e. the agreed spec, AND the testing documents showing the client certifying the software satisfying most of the spec, etc)".  Many times, the client will back off and at least pay partially, because otherwise he will have some very difficult explanation to do when his boss ask why the project is canceled at the last minute even when it is working according to the agreed spec.

''Or your boss(or your boss's boss) decides it's not worth the bad blood and tells you to make the change and send it to the customer. Telling customers to piss off doesn't happen in the real world''

Many of these scenarios are instances of TheProcessIsTheProblem: A customer makes unilateral requests or changes without concern for the costs. Perhaps this bad process was codified in the customer's contract. (Maybe whoever agreed to the contract needs to be replaced, PeopleAreTheProblem.) In other cases, the customer is paying for time and materials, so he pays cash for any additional work, but he needs to understand there are also non-cash costs when requirements changes: increased risk and longer time-to-market.

''I have usually found that customers usually do not just invent new requests or demand changes out of the blue.  This is usually an indication that the customer was not involved sufficiently during the development process.  When a product hits actual use and fails to do what the users need it to do, there is a real cost, though perhaps unmeasurable.''

''My point is that this situation usually indicates a break down in communication and communication requires two parties.  Both parties are responsible for improvement in communications, hence this is a process problem and trying to blame one side or the other is counter-productive.''

''Costs due to product misperformance will be felt by both the user side and the developer side, and, assuming a valid cost/benefit analysis was ever performed, the user side costs will dwarf the developer side costs.  Avoid the blame game.  --WayneMack''

As soon as your boss asks you to do a week and a half of work in a few days, without then giving you a week of compensation to goof off and take it easy, he's shown TheManagerIsTheProblem. Even worse to expect weeks of long days, uncompensated. ThereAintNoSuchThingAsaFreeLunch. Someone's got to pay the piper. If management expects the staff to pay these non-monetary costs, rather than the customer, it should expect to lose the best staff it has to its competition.

''Manager's perspective.  Sometimes I need the technical people to provide a time effort.  I will probably know a description of the problem and a target resolution date.  I probably also do not have a detailed list of your current work load sitting in front of me.  If I come in and say, "Al and Bill, our customer has this problem, can we fix it by next Tuesday?" don't just go out and start working 16 hour days through the weekend to do all your current work and produce an ideal solution.  Tell me what is feasible, for example, "We can address 2 out of 3 of the problem areas by next Tuesday, but we'll also have to defer work on project Z while we're doing it.  This allows me to negotiate with the customer with some facts in hand.  We may descope the problem further to get an earlier solution, we may agree to delay the solution for more completeness, we may need to go ahead and do the overtime thing, but at least I can justify the overtime with the HR monster and get compensatory time off in an above board manner. ''

Good for you to be such open minded manager.  But I doubt the topic in question is caused by such managers as you.  I have seen managers who absolutely hates answers such as yours, they just want a "Yes" and that's it (answering "No" is implicitly forbidden.).
----
''Or your boss(or your boss's boss) decides it's not worth the bad blood and tells you to make the change and send it to the customer. Telling customers to piss off doesn't happen in the real world''

May be not in your real world, but in my real world where I worked for real company with real boss for real customers paying real money to build real systems, if my real boss sense that a piece of real work for a real customer is not likely to be paid for, that customer cease being a customer.

Perhaps a middle manager working for gigantic nameless corp can afford to sink month after month of resources for a customer with track record of changing his mind in the last minute and refuse to pay for work already done according to agreed spec.  But many smaller companies like the one I worked for simply cannot afford to play these games, if my boss feels the deal is not working out, cutting his losses sooner rather than later is a sensible option. -- The same Someone else as above.

''True. But there is also the case of a customers who are paying for both large and small projects. Most companies won't risk the large projects for a little more work on the small ones. It's not any different from a spouse or child "needing something right now", you can tell them "a lack of planning on your part doesn't constitute a crisis on mine". . . but in the end you'd probably bail them out. ''

''Also, there is the case where one of the customer's equipment breaks, and possibly a new version, or a change to some software, is needed. In those cases, the good blood created by helping the customer is . . . well. . . just good business. Of course it can be taken too far, but TheCustomerNeedsItRightAway is usually a day or two thing, not weeks -- LCT'' 

Firstly, I doubt such a day or two thing that rarely happens will cause a rant such as this page.  Secondly, if these are really rare "a day or two thing", and the company is getting compensated from the profits of big projects, the affected programmer would have no problem getting extra compensations for it, right?  Sadly, from some personal experience and stories of other collegues, these things are fairly common (though not from the same project), and is usually highly customer dependent.

Some customer have a habit of giving these kind of last-minute requests, partially encouraged by success at getting what they want from previous experience.  Managers that takes these customers know it, and knowing these requests are not rare, willing not compensate his programmers for it because it will significantly eat into his budget.  Thus he maintains the profits of his projects by making his staff absorb these costs.  I just happens to be fortunate enough to have worked for a boss who don't play these games, and got the guts to say "no" to unreasonable requests.  Even if such requests were accepted (as you say, sometimes shit does happen), the programmers were compensated fairly for it.

This is not to say it is completely the manager's fault, but by accepting the request and refusing to compensate his staff, the manager is not doing his job.  In that case, it is the programmer's choice to meekly accept it, discourage it by doing the job screaming and kicking, or flat out refuse and/or go find another job, or some combination of the above.