It's not too different from that situation where someone says "how can I do X" but when you drill down on why they think they want it, there are better things they should be focusing on. Deadlines are about synchronizing different groups. The problem is opaque/arbitrary deadlines. "Why we need it by then" and "What exactly is needed by then" are very important conversations. Pushing for speed at all costs is bound to destroy morale and quality.
> Deadlines are about synchronizing different groups
If we agree that software frequently runs late (and this is backed up by plenty of research) then deadlines necessarily won’t succeed in this role.
Instead, we should be identifying the points where synchronisation will be possible, and using these as triggers.
For example, we could say, “when this set of features F is running with performance P and is passing tests T then we have 2 months to develop a marketing campaign”.
As an enterprise product developer, I’ve been involved in maybe 100 software projects in three industries and I’ve pretty much never seen a situation that actually needed time based synchronisation. The projects launch when they are ready - deadline or not. While my projects were typically small (3-6 months) they were key infra for the businesses I was serving.
Deadlines definitely serve a purpose but given that software is almost always late, using them as a sync point is just asking for failure.
