You cannot fill a vessel that has no bottom. We all know this. And yet, every Monday morning in software teams across the world, someone says “there is one small change in the requirement” and we all smile and say okay. By Friday, you realise you have been filling that same bottomless vessel the whole week and nobody noticed because each drop was so tiny.
Every team involved in building software, whether it is business, product, or engineering, is trying to do the right thing. The business wants to build something that actually works for the end user. Product wants to capture every important detail. Engineering wants to deliver something that lasts. The problem is not intent. The problem is process. And one specific process failure that quietly destroys delivery after delivery is the endless loop of changing requirements with a deadline that never moves.
This post is about that loop. And more importantly, about what a better approach looks like.
The Pattern Most of Us Have Lived Through
It usually starts well. Requirements are gathered, the team does its estimation, work begins. Things look organised. Then, somewhere closer to the delivery date, a review happens with a wider set of stakeholders. Gaps are found. Some things need to change. The release is pushed. A new date is set.
So far, this is not unusual. Adjustments happen. The world does not always cooperate with the original plan. What happens next, though, is where things go sideways.
The new date is set, but the requirement process does not fully close. Discussions continue. Every week there is a clarification. A small change here. A revised flow there. A module that is still “being aligned.” Each of these changes, on its own, looks minor. One field added. One validation updated. One step reordered. Nobody calls an emergency meeting for these. They just get absorbed.
A tiny drop of water does not seem like much. But over years, constant dripping wears down even the hardest stone. Tiny daily changes to a requirement, absorbed silently by an engineering team, do the same deep damage to a project.
And through all of this, the deadline does not move. The message from above is usually something like “the requirement flow cannot be stopped, but the core should be frozen for delivery.” What counts as core? Still being discussed.
What Analysis Paralysis Actually Costs
Analysis paralysis is usually described as being stuck and not deciding. But in real project environments, it does not look like inaction. It looks like a lot of activity that is not converging. Meetings happen. Documents get updated. Presentations are made. But the signal that engineering needs, which is a stable, agreed, committed requirement, never quite arrives.
This has real costs that never show up in any status report.
When a developer spends two weeks building a module and then gets a requirement change, they do not just change one line of code. They have to mentally rebuild the whole context of that module. Tests written for the old behaviour become invalid. Design decisions made upstream now propagate their changes downstream. The cognitive load of this kind of rework is exhausting in a way that is hard to explain to someone who has not experienced it.
If the deadline stays the same but the work keeps growing, the team will lose focus on quality. They will miss out on security and performance testing just to finish on time. This creates software that is fragile and difficult to maintain later
None of this is because engineers are careless. It is because they simply do not have the time to think. And engineering, at its best, is mostly thinking.
Deadline Problem is a Scope Problem
There is a well-known triangle in project management. Time, scope, and quality. You can control two of them. The third one adjusts itself.
When a deadline is fixed and requirements keep arriving, scope is effectively expanding. The triangle adjusts by reducing quality. This is not a failure of the team. It is arithmetic.
The conversation that is often missing in escalations is this: what gets removed from scope to accommodate what was added? Adding a requirement without removing something else is not a free action. The cost is paid somewhere, usually quietly, usually in quality, usually discovered after go-live.
Senior stakeholders who insist that both the deadline and the requirement flow remain open are not wrong to want both. The business need is real. But this position needs to come with an equally clear statement on what gets deprioritised or what gets phased into a future release. Without that clarity, the only people carrying the full weight of that contradiction are the engineers in the team.
How to make it work?
The goal is not to stop requirements from evolving. Requirements should evolve. Business understanding deepens as development progresses. That is healthy and normal.
The goal is to make the impact of each change visible and to make intentional decisions about it, rather than absorbing it silently and hoping for the best.
Freeze with meaning. When a freeze date is announced, it should carry weight. Anything coming after the freeze date either goes into the next release or it needs a formal impact assessment before being taken up. A freeze date that everyone nods at but nobody holds to is not a freeze date. It is just a calendar entry.
Make change impact visible. Every change after a freeze should get a quick estimate of how many days it adds and what it affects. Even a rough one. When the business sees “this change adds three days and affects two other modules,” they can make an informed decision. When they never see that, they keep adding drops to the vessel without knowing the vessel is already full.
Separate delivery from discovery. Some organisations run discovery and delivery in parallel. The teams doing requirements analysis for the next phase are doing their work while the development team is building the current phase. This is a perfectly healthy approach, as long as the channels do not mix. Discovery findings should not become in-flight changes to what is already being built.
Give engineering time to think, not just type. The best engineering work happens when a developer has a stable spec, a clear understanding of the boundaries, and enough runway to think about the things that are not written in any document. The performance implications. The failure modes. The edge cases that only become visible once you are deep inside the problem. This thinking requires peace. You cannot hit a target that keeps moving. Developers need a stable plan to think through the small details. If the requirements change every day, the thinking process simply stops.
Rushed Delivery is Not a Saved Deadline
This is perhaps the most important thing to say. A team that ships under impossible conditions does not save the deadline. They borrow against the future.
The production incidents that come three months later, the performance issues under load, the security vulnerabilities that were never tested for, the maintenance nightmares that slow down every future sprint. These are the repayment of that loan. And the interest rate is not small.
A delivery that looks complete on the surface but is fragile underneath does not serve the business. It serves the deadline. These are not the same thing.
The teams that consistently ship quality software are not the ones working the hardest under the worst conditions. They are the ones where freeze means freeze, and scope change means timeline change. That kind of culture does not build itself. It has to be chosen, deliberately, by the people who set the deadlines and manage the requirements.
The aim of writing this is not to point a finger at anyone. Business analysts, product managers, delivery leads, and senior stakeholders are all doing their best with the information and pressure they have. The aim is to name a pattern that most of us recognise and to say: we can do better, and we know what better looks like.
Better looks like requirements that are respected once frozen. It looks like deadline conversations that include scope. It looks like engineers who have enough breathing room to do their best work. And it looks like deliveries that are proud, not just done.