I believe this also depends on who you ask

For me deadlines are simply "someone wants this and this delivered @" I work on it a couple of days and then I tell that someone if it's reasonable and if it's not reasonable, what they are gonna get instead.

Most of the times deadlines are way off the mark and it also happens that they take 1/3 of the planned time, in that case instead of over engineering, I simply rest or study something new.

Over engineering is a curse only if one can't stop doing it and needs an external stimuli to mark the feature as "done".

Otherwise I believe most programmers know when their work is finished and can be shipped.

Sure! I currently work at a place where there are deadlines and no sprints. It works very well for me, and for the company too apparently. There are customers who expect their stuff to be shipped and the product has a month by month roadmap.

Now, over-engineering is a risk but I think I'm lazy enough to avoid it most of the time. I probably have the opposite issue sometimes.

We do get things done without running for a deadline most of the time though, so it works okay without deadlines for the some non negligible part.

We'd be dead if we didn't release. There isn't any investor's money to compensate.

What early Agile knew and Scrum has obliterated is that basic advice you got from your high school or college teachers who pointed out if something is important you can't leave it until the last moment.

The counterargument about deadlines is always some sad sack story about shipping for the holidays or having tax software done in time for the start of the tax season. Those stories are all true, but they have fuck all to do with deadlines.

Continuous Delivery means that if you need something by Friday, the conversation is about the relative risk/reward of shipping the build we're going to do on Tuesday, or the one we did last Tuesday, or one from three weeks ago. Not whether the important features will be done by CoB on Friday. Because the critical bits of the important features were finished over a month ago and now we're just making everything pretty.

What happens is that "the work expands to fill the time" is not just a law that applies to developers, it also applies to management in spades. "Sure, we need this feature, but why don't you hold off on doing that while we do this other thing that feels important but only because I told someone it would happen and I'm too much of a coward to tell anyone that I was wrong about something, and I outrank you so you and your social life are going to pay for my mistakes, not me and mine."

The problem is that deadlines are often too tight because the person responsible is usually not the one who suffers the most. If this is the case, the result is low code quality and bad feelings because the developers are either overworked or feel guilty. Instead, it is best to create a priority list of tasks and review it regularly.

I agree deadlines are a necessary evil to ensure we hold ourselves accountable to both customers and internal non-eng stakeholders who need to know when things will ship in order to make plans around them and collaborate with us effectively.

One approach to develop a healthy culture around deadlines I've been thinking about lately:

Plan the deadline around the minimal lovable product, while spec'ing out the minimal shippable product, and ensure there's enough of a delta between the two so we can have a large degree of freedom w.r.t. scope.

Without this freedom to vary scope, _when_ (not if) our estimates invariably fail, our only options would be to extend the deadline (defeating the purpose of setting deadlines in the first place if we resort to this often enough), or to burn ourselves out with overtime work in an attempt to meet those deadlines (obviously results in an unhealthy/unsustainable environment, and not even guaranteed to succeed).

I think for junior developers that might be true. Does the name connect? :)