No, shipping code to production on a weekly basis is not a deadline. A deadline is a time by which a task must be completed. A task is something like "fix bug 3831" or "allow users to log in with OAuth2". "Ship code" is not, in any useful sense, a task.

Such "timeboxed iterations" can indeed result in "shipping" a null update. Unless you have a time-consuming QA gate to pass, that's not very likely, especially on a team containing several people, but it can happen. You don't know that you will have "something" to ship.

Typically we try to break changes down into shippable tasks that can be done in under a day, so the expected number of tasks completed by a four-programmer team in a week is on the order of 30, or 15 if you're pairing. For this to fall all the way to 0, everybody has to be spending their time on things that could not be thus broken down. It's pretty unlikely to happen by chance. But sometimes a difficult bug or two really is the thing to focus on.

In XP, estimates are used for prioritizing which tasks to work on and which tasks to break down into smaller tasks. The "product owner" is supposed to choose the tasks that have the most user value for the estimated cost. But those estimates aren't commitments in any sense; they're guesses. Sometimes tasks take more time than estimated; other times, they take less. This is the reason for the shift to estimating in "story points": to prevent the estimates from being interpreted as referring to a period of time.

If someone in your organization is interpreting estimates as commitments, this can have a corrosive effect on the accuracy of those estimates, because estimators respond by padding their estimates, in inconsistent ways. Often this destroys the usefulness of the whole iteration planning process, because the project owner no longer knows which tasks are the easiest ones and thus worth doing even if the benefit is marginal. Organizations can recover from this pathology in a variety of ways, but often they don't. Eliminating estimation is one response that sometimes works.

Yes, this sounds very familiar to me. I started with dates and went to story points used to estimate dates. Then as we turned up the release cadence, we eventually dropped estimating altogether, even in points, because it wasn't really helping anything.

That doesn't mean we refuse to solve the problems that estimates are used to solve. E.g., "Can we have something by the big conference," or "Can we keep our customers happy." We just solve them other ways.

And totally agreed about the corrosive effect of treating estimates as commitments. It's such a negative-sum game, but people play it all the time.

I already said this to your fellow interlocutor who is also responding to nearly every comment of mine with the same thought process, but I'll say it here as well in different terms:

The product owners, customers, salespeople, supervisors, peers, etc. you interact with as part of the software development process on any project outside of a personal hobby don't care about your semantic games.

If functionality is needed in an application, and they ask you to implement it, and you agree, there is no real-world scenario where they just say "Cool, I'll sit idly by while you work at this until you declare it ready, and then and only then will I let anyone else know about it or take any action on its supposed existence," and repeat that for every piece of functionality you implement in perpetuity.

And if you keep failing to deliver required functionality over time, no one is going to accept your arguments that: "Oh sorry, our weekly deliveries to production aren't a deadline, it's a timeboxed iteration", "Oh that estimate wasn't a commitment to do anything, we work on our own schedule", and so on.

Yes, the relationship between developers and "other stakeholders" can turn toxic, but in most organizations the developers don't have much power, probably due to repeated attempts to play the games you've laid out above. The way to combat that is to be reliable and professional so your team has the authority to stand their ground on the difficulty of a given task, not effectively refuse to participate in what is a completely reasonable conversation about the relationship between your work and the objectives of the organization.