>This is absolutely necessary for doing business.

Yep! It sure is.

FWIW, I've spent most of my career producing custom software for paying customers. I've never missed a deadline because the the contacts I've worked on were negotiated appropriately. I've worked a whole total of 1 hour unpaid overtime in my entire career (and that hour was completely my choice).

If the people negotiating these contacts didn't know what they were doing, the companies I've worked for over the years wouldn't be in business anymore. I'm glad I've only worked at functional organizations.

So, yeah, the first few sentences of the article were completely foreign to me, yet the author claims, with confidence, to speak for everyone. Didn't bother reading the rest.

How were the contracts "appropriately negotiated"? Did you have a fixed number of paid hours upfront where you created detailed requirements together with the customer that you all agreed to? And then you estimated every requirement based on solid experience doing similar work, multiplied by 3.14, got a "let's go" from the customer, sat down and implemented according to requirements and then delivered to customer within budget/in time? And when the customer found out that they wanted a certain feature to work another way. Then you put in a couple of hours to work out the new requirement and set up a new contract, properly estimated and delivered in time/within budget?

The mind set of working without planning and deadlines, caused by an inability of organisations to do so, is really troublesome. Using Agile as excuse is even worth.

There's 3 approaches.

Deadline & No Fixed Scope. Fixed Scope & No Deadline. Deadline & Fixed scope and padding appropriate to uncertainty to hedge risks.

All 3 are admissions you can't estimate accurately.

In my experience you choose between schedule and quality, which is in line with your point I think.

“We release when it's ready" is focusing on quality only, and deadlines are just fictional dates, and “we release whatever is ready in time” is the real world process, where the product is bargained to whatever can meet the deadline (in the airplane example, that would be redefining your destination as wherever the plane is at the designated landing time, and see you in court if you ever make it back to civilization)

I think few people understand that setting deadlines equals to choosing the second strategy though. A mix of both just puts it in the first camp (“deadlines are flexible”)

Nothing happens in a vaccum, other parties tend to depend on your deliveries whatever they are. And those things are interconnected, if now everybody "focuses on quality" and delays things nothing gets done at all and not just late.

The focus on quality is limited by what you call “ready”. If it’s a reasonable definition, it will delivered in a reasonable time (you just don’t know exactly when)

The same way setting unreasonable deadline will only bring unusable results, which won’t help anyone interconnected to you.

It all comes down to proper management, there’s no magic way out of it.

Only in a team of slackers. Some people are intrinsically motivated to do great work and be productive. They don't need fake dates to get things done.

But they need direction and alognment if they want to function as a team let alone an organisation. And that includes deadlines.

coordination =/= deadlines

Think about teaching your kids peogramming. Do you set deadlines on when they need to finish learning to read, when they'll touch their first computer, the date they need to have a working hello world ?

For any of these you'll probably be buying toys, books, discuss with your partner and arrange time etc. But none of those will be "deadlines", even if you intend to be very optimal in the progress

Kids learning something is quite the opposite to conplex projects out in the professional world. Coordination without schedules won't work, and schedules include deadlines for certain milestones.

I think it's pretty similar, and what many think of as deadlines aren't, in the sense that they are flexible.

For instance infrastructure projects: a delivery date is set, but developpers blowing out that date is just a fact of life. What will you do anyway when your new dam or highway is 6 months late ?

Even at smaller scales, you'd schedule moving to a newly built house at a set date, but painfully know the developper can easily blow past that and you can't just take the date for granted, or you accept moving to an unfinished house.

Software projects are of course the same, at big and smaller scales. Just look at game delivery for the most piblic instances of setting "deadlines".