Imagine you’re going away on holiday. You decide where to go. You book a hotel. You book flights. You decide what you’re going to take.
So you make a list. Then you take the things on the list, and you put them in the suitcase.
Then you close the suitcase. You take it downstairs and put it in the car. You drive to the airport. You park, and you check in, putting the suitcase on the conveyor belt scales. Then you go through security and drink some overpriced coffee or beer. Then you get on the plane and sit in discomfort for a few hours. Then you wait to collect your suitcase from the carousel, and you go to your hotel.
At any point during this process you can realise you’ve forgotten something, or you can change your mind about what you wanted to take.
The later in the process it is, the more complicated it is to change your mind.
If the suitcase is already in the hold, it’s too late. All you can do is get annoyed with yourself, and buy more stuff if you really need it. By the way, you probably don’t really need it.
If you’re at the airport, but haven’t checked in, you can either buy some extra overpriced stuff, have a frantic drive back home, or just live with it.
If the suitcase is already in the car, you can still get everything out of the boot and swap things around. You might still make it to your plane on time, but the whole thing just becomes much more stressful, and you’re more likely to exceed the weight limit if you put more things in.
If you’re still at home with the suitcase open, there’s no problem at all, unless you’re running late.
If you’re still at the point of writing the list, you can afford to change your mind as much as you like.
Now think about a software project. There’s a process involved, and it seems to be fairly well established that the cost of change increases the further through the process you are.
This is why we get annoyed at late change requests. Having said that, there’s a certain twisted pride in working ludicrous hours to get stuff done. A lot of developers weirdly enjoy the pressure, and imagine that they work better like that, but those stressful rush jobs are when the bad bugs happen, and when technical debt creeps in.
The trouble is, if the team pull out all of the stops to get the change in on time, they’ve set a precedent. The client gets the impression that last-minute changes are possible. And they will ask for them again. And again.