I do largely agree with you, except here: > Deadlines are about synchronizing different groups If we agree that software frequently runs late (and this is bac

I do largely agree with you, except here: > 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.