This makes no sense at all. The business needs to make money to pay you. Your time is the development cost of the software. It is completely reasonable and rational for a company to say, "This is valuable to us if it can be built in three weeks, but if it takes longer, we don't want it." Because three weeks of paying your team costs a certain amount of money, and a cost higher than that puts the value of the work underwater.

If you cannot forecast whether it can be built in three weeks and then deliver against that forecast, you aren't doing your job.

> Wasn't agile created to solve this BS?

Agile sets regular deadlines for shipping to customers, that is literally the core idea. Instead of one big deadline 6 months from now, you have a small deadline every two weeks for the next 6 months. It's still a deadline.

You want milestones and progress over estimates and deadlines.

The value equation of a software development team isn't a product of their time and salary compared to the code/features/whatever-unit they produce. It's the theories and knowledge they build in their heads and share through the process of understanding problems and developing solutions. You can't optimize that process in a Taylorist fashion.

If there is a process called Agile that's still useful, it's built on this manifesto that eschews management in the Taylorist sense. The principles are built on a preference for organizations driven by the workers rather than the managers. It was perhaps too radical and too naive.

"It gets done when it gets done," is a glib way of saying that progress is more important than deadlines. The idea that systems take time and what's important is that people know where we're at and where we're heading more than threatening punishment for not delivering what we estimated at an agreed upon time.

> The value equation of a software development team isn't a product of their time and salary compared to the code/features/whatever-unit they produce. It's the theories and knowledge they build in their heads and share through the process of understanding problems and developing solutions. You can't optimize that process in a Taylorist fashion.

There is no value equation for "the theories and knowledge" that developers build in their heads. Value in software happens when customers pay for software. That's how business works. It happens to be true that developers need to build theories and knowledge in their heads, but that isn't unique to software engineering and doesn't prevent deadlines from being effective.

> "It gets done when it gets done," is a glib way of saying that progress is more important than deadlines. The idea that systems take time and what's important is that people know where we're at and where we're heading more than threatening punishment for not delivering what we estimated at an agreed upon time.

I understand the argument, having heard it from teammates ten thousand times in my career. I'm somewhat sympathetic to it, but it is not a full picture of the software business. A business that fully adopts such a strategy has no long-term plan and can't make promises to customers. That can work if you lucked into all the money in the world (Google), but most of us are not so lucky and need to deliver to customers within reasonable timeframes or the customers go to someone else who can.

I get that estimation can be hard, conversations about scope can be hard, and managing expectations can be hard. I don't care. If you still have a job in this industry you are extremely well compensated to overcome those difficulties.

If you don't care, I can't help change your mind.

I took a small company that was living contract to contract into a world where they started making millions in annual recurring revenue.

There's no secret, magic bullet. All I did was make sure we were delivering progress at a regular cadence. Kept communication channels open. And tried to, but ultimately failed at, training the sales team to stop with the secret deadline negotiation.

I understand the sales cycle at the enterprise SaaS level is a long song-and-dance of promises and and punishments. I understand that money only changes hands when the customer feels like they will get their money's worth or else your business will go out of existence. It's a difficult game to play.

However... they were never unhappy. Steady, reliable, and consistent beat out guessing, promising, and hoping to deliver every time. The dollars proved it.

I think we're talking past each other.

> I took a small company that was living contract to contract into a world where they started making millions in annual recurring revenue.

> There's no secret, magic bullet. All I did was make sure we were delivering progress at a regular cadence. Kept communication channels open. And tried to, but ultimately failed at, training the sales team to stop with the secret deadline negotiation

This is what I call hitting deadlines.

> I think we're talking past each other.

Perhaps. I'm not saying that deadlines don't exist or shouldn't. I am saying that they're often unnecessary and most software teams can deliver value without them.

If you're in the embedded space there's no dodging deadlines. If you need to flash ROMs it could be months before you can do a release if you miss your deadline. You might not have enough money to survive until then.

If you're shipping boring, line-of-business enterprise SaaS you don't need deadlines. Customers want software that solves their problems and are happy with something that works for 80% and a steady rate of improvements over time. They want progress and milestones. There's nothing wrong with taking an extra week or month to reach the next milestone.

Where you get the "deadlines equal dollars," mentality in enterprise software is from the long sales cycle with the big price tags. A business is going to have reservations about dropping a few hundred thousand on a new software product. And so you end up with these negotiations between sales, management, and the software teams where you're lying about the deadlines to different parties in order to keep everything in line. I don't think that's a good way to go about it.

Especially when most of the time it's not even necessary. This was the finer point I was often finding myself in opposition to the sales folks with. Their reality was that deadlines are a negotiating chip they can't ignore. The software developers' reality was that any estimate about a deadline is completely made up of hopes, dreams, and unicorns. The easiest way to get people to work together, in my opinion and experience, is to cut out the lying and just be honest.

Some organizations like that, some don't. I went back into being an IC because I just can't operate at that level and keep my sanity/energy.

While I agree with your framing of the discussion, the fact still remains that in business there are many areas where deadlines are required both because (a) time is literally money - if you believed it would take X days to release a feature, but it ends up taking 3X, it could have been the case that, in retrospect, we never would have then implemented that feature in the first place, and (b) there are often many other people working on a project that need to be coordinated - try managing that process if every team just gets to say "it takes as long as it takes".

The industry is littered with software development teams that guessed when they could deliver something and failed.

If business can only depend on "this happens first, then that," well... they're either going to get lucky or fail.

It's just not how software development works. Knowledge work isn't a line in a Toyota factory. Scrum and agile all you want.

As someone else in another thread put it, you don't throw out your work just because it was delivered late. Knowledge is valuable regardless of how long it takes to acquire it.

I think the person you replied to would consider your description of agile to be === "it gets done when it gets done." Despite the term "deadline" used to describe "expected completion date" in agile they're not actually deadlines--you don't throw the work away because it's useless if it's not completed in time.

Please introduce me to the fantasy world where everything else can survive without deadlines and schedules.

As an engineer, I don't like deadlines either given how unpredictable large scale software development can be, but the fact of the matter is that most software is in service to a business, and businesses need to run on schedules. If you don't like that, you shouldn't be working in a software business, you should be working in a research think tank or academia.

To add, coming from a research environment (industry AI researcher turned community college professor), there are deadlines in industrial research labs and academia, too. All of my industry research projects had to fit within management-defined schedules. Back in grad school I was well knowledgeable of the “call for papers” deadlines of all the major conferences of my field, and my professors also were well aware of the various deadlines for applying for NSF grants.

I hate project estimation with a passion, especially when doing research, but I recognize that funding isn’t infinite and funders want to assess their own risks. This, we as researchers and engineers have to try our best when it comes to project estimation, even though there are so many “unknowns.”

The only situations that I could think of that are free of deadlines and estimation pressures are projects that are not on the “critical path” of a business or organization, such as a tenured professor working on a project where the outcome doesn’t negatively impact job security, or a student’s side project (like Linux circa 1991) where the only constraint is time.

>Deadlines aren't for tech teams.

Uh, that's just wrong. You may have contractual deadlines for delivery that are real and meaningful, for example.

>When someone asks for a deadline, the answer should be "it gets done when it gets done."

A refusal to engage in meaningful discussions about forecasts does not free you from the obligation to meet one. You must might not like the one you get imposed on you if you refuse.