People start talking a bit faster, typing a bit louder, and suddenly there’s an air of impending doom.
That’s right — the Great Flap has begun.
You can almost feel it in the corridors (or Teams calls).
The sense that if this particular bit of software isn’t live by Friday afternoon, civilisation as we know it will collapse. Cats and dogs living together. Total anarchy.
The myth of deadlines in software development
It usually starts with someone saying, “We’ve got a tight deadline, but I’m sure we can make it if we all pull together.”
Ah yes. That old chestnut.
Because nothing motivates quite like the unspoken threat of collective disappointment.
The deadline, of course, was never realistic. It was set optimistically in a meeting some weeks ago by people who do not, and never will, understand what “refactoring a data model” actually means.
But now here we are, marching valiantly towards an impossible finish line, as if sheer willpower and a few motivational emails will somehow defy the laws of time and logic.
Why software development takes time (and can’t be rushed)
Here’s the thing. Software isn’t an emergency service. You can’t just switch on the sirens, shout “let’s go, team!” and expect miracles.
It’s an art form — slow, deliberate, and occasionally maddening.
It requires thought, patience, and the ability to spend three hours wondering why something doesn’t work, only to realise you missed a semicolon.
You don’t become an expert overnight. You don’t take a thousand vague requirements, a handful of “blue sky thinking” ideas, and end up with the digital equivalent of the Holy Grail.
But try explaining that to someone who thinks “agile” means “done by next week”.
How project spreadsheets create false deadlines
No Great Flap is complete without the sacred text: the project spreadsheet.
Usually named something like:
ProjectPlan_FINAL_NEW_latest2(1)_USETHISVERSION.xlsx
Inside, you’ll find a riot of colour — red cells, amber cells, inexplicable greens — and formulas that worked perfectly on some long-forgotten project but now throw up #VALUE! errors.
There’ll be a tab called Risks with two items on it (“Christmas holidays” and “staff sickness”), and another called Lessons Learned which, naturally, is empty.
Why teams push for unrealistic deadlines
Then comes the pushing.
“Just one more sprint.”
“Just one last push.”
“We’re nearly there!”
We are not nearly there.
We are, in fact, somewhere between despair and déjà vu — that familiar territory where everyone’s pretending this time will be different.
Some developers push back. Others smile politely and get on with doing things properly, at their own quiet pace. Because we’ve all learned that panic doesn’t make software appear any faster. It just produces tired developers and broken code.
Why experienced developers ignore unrealistic deadlines
So, what do you do? You nod. You smile. You attend the daily stand-up, listen to the pep talks, and then quietly go back to your desk (or kitchen table) to do things the right way.
You focus on quality, on craft, on not being the person who signed off a bug-ridden disaster because someone shouted “urgent” enough times.
And when the inevitable happens — when the deadline slips, the panic subsides, and everyone suddenly decides it’s fine after all — you just sip your tea, raise an eyebrow, and carry on.
Because unrealistic deadlines don’t speed up software development — they just make bad outcomes more likely.
Because you’ve seen it all before.
You’ll see it all again.
And deep down, you know that calm competence beats frantic enthusiasm every single time.
If deadlines in your project feel more like pressure than a plan, you’re not alone.
I spend a lot of time helping teams cut through unrealistic expectations and get back to something that actually works.
If things feel rushed or out of control, take a look at my TechFix service.
