[danparsonson]

Alternate view point - driving projects to a specific deadline allows the other departments in the company to coordinate marketing, packaging, and selling the product. These people don't sit on their hands patiently waiting for engineers to finish building, their work can take many months just as the development does, and sometimes also involves making tradeoffs to deliver on time. No company wants to wait another year after development is finished before they start earning money for it.

[pjc50]

Yeah, this is an unfortunate truth that Agile has to confront; there may be hard coordination deadlines. Or, in startups, a financial "runway".

On the other hand, setting a deadline can't force something to be possible, it can only force people to work harder and more painfully towards it. I'm sure the Amazon drone delivery failure had a date target, for example. And there have been plenty of failed "big bang" IT migrations delivered by similar immovable deadlines.

[madeofpalk]

If anything this is the reality of shipping software that "agile" is designed to handle.

It's so you can (hopefully) have an educated understanding of setting that deadline, and then how you're progressing towards it. It's so if you're not on track to deliver, you can make more educated decisions about cutting scope, or adding resources (yes yes yes, i know).

[jnwatson]

Agile is fine with fixed due dates. Fixed features on the other hand...

[Jtsummers]

Exactly this. You create a minimum set of features that must be shipped by the due date. You negotiate on this, adjusting the minimum set or the due date correspondingly.

The desired features beyond the minimum set are accepted as being at risk of remaining unimplemented if the due date can't be shifted further to the right. They become stretch goals that may be achieved by the deadline, or will be worked into a second effort during the maintenance of the system.

Agile (especially some of the stuff in the Lean Software world) is very well-suited to this kind of development. As are the classical evolutionary or iterative & incremental models.

[ilaksh]

You have to try to understand that building software is not like baking a cake in a custom shape. Which if you have seen those shows it requires a certain amount of ingenuity to create a cake shaped like a fountain. Or whatever.

But fundamentally software development has 1000 to 1000000 more moving pieces than a cake, generally a research project, like building a new type of aircraft engine. Except, imagine it was a really new type of engine that was being built based on an alien landing. But they could not get into the engine to see how it worked because it was an unknown alloy. So they were trying to invent a new type of anti-gravity drive based on a few clues.

I mean we are not trying to defy gravity, but there a shitton of unknown unsolved problems. You can't promise or create marketing for a feature unless we already know it's possible. For starters.

But the issue is worse than that. What generally happens is once one part of the new engine is barely working, they demand another new invention that has to be completes in the same deadline before the other one has corner cases examined even.

[danparsonson]

Sorry only just saw this.

I'm a software developer, have been for my whole career, so I know what building software is like. And while I agree that sometimes there are significant unknowns to resolve, and these can require large amounts of time, still the company has to market and prepare to sell the product before it's finished, otherwise as I said the company has to wait months or even years to get paying customers, by which time a) they'll have burned a huge amount of money without seeing any return and b) they may have missed their market opportunity. In the case of B2B transactions, the customer may have made significant operational decisions based on the deadline they've agreed to, and the supplier missing that deadline can have serious repercussions for a relationship that may have taken many years to build.

And come on, let's be honest - most of the time we're not designing a new type of aircraft engine. We're building something that looks very much like existing engines in general form, but with specifics that are different. I know it's hard, and I know estimates are a significant source of pain, but we need to have some sympathy for the rest of the company that's ultimately bringing in the piles of money that we get paid.

[quickthrower2]

And you don’t really know if anyone wants an engine, although the word got banded about in some initial conversations. You could ask the customer but they want faster horses, and you are not allowed to talk to them anyway as you are assumed to not have stakeholder skills plus you are paid too much to not be coding.

[thow-01187]

Furthermore, financial penalties on late delivery are not uncommon in enterprise business-to-business settings. These penalties are sometimes quite steep

If the choice is between releasing kinda-working, but unpolished software, or throwing a developer's monthly labor cost out of the window every single day, these management anti-patterns suddenly make much more sense

[Forge36]

I business agreement isn't an arbitrary date. Those dates should be clearly communicated to engineers.

[danparsonson]

They are communicated to engineers - in the form of deadlines...

[spaetzleesser]

Problem with a lot of deadlines is that you aren’t told if this is a hard requirement because of a contract or some other external factor or just an ego trip or wishful thinking of upper management.

I have seen it plenty of times that management pushed for an arbitrary deadline. The deadline passed, project was not done and nothing bad happened other than another new deadline.