Hacker News Reader

Comment by PragmaticPulp | Hacker News Reader

It’s always fascinating to read these anti-deadline articles that assume deadlines are arbitrary things that exist for no reason.

That might be moderately true for, say, someone developing a new app feature that gets shipped to users who aren’t expecting it. However, it’s not true at all when the software development output is a gating feature for real-world contractual obligations and other such business drivers. In that case, target dates must be carefully forecasted and estimates must be performed with great care and detain. This doesn’t guarantee that a target date will be hit, of course, but it’s not impossible to produce estimates that are reasonable accurate a large percentage of the time.

Estimation, planning, and progress tracking are difficult skills that must be learned, but they’re not impossible. I suspect many of the developers who believe that target dates are always arbitrary, pointless, and impossible to estimate have mostly worked in big cash-rich environments where it didn’t really matter when a feature shipped. If you go to the other end of the spectrum and talk to engineers who work in industries where target dates are critical you’ll discover a lot of people who are very good at breaking down projects and accurately estimating dates without relying on crunch time to get things done. It may sound impossible if you’ve never worked in an industry that requires such precision, but it makes sense after you’ve worked in such an environment for a while.

View on HN

Most deadlines in my career so far were arbitrary. Sure, some deadlines were driven by fixed events, for example Christmas promotion has to be launched before Christmas.

But in most cases when I asked managers about the reason behind the deadline, the answer was something like "oh,I promised this team/director we'll do it by then". When I dug deeper to see what happens if we miss the deadline, it appeared the said team would be just fine, there were no real life consequences, just that they wanted to finish their part of work by certain time, and they depended on us.

I'm not saying deadlines are useless, but they're very often driven by some arbitrary promises made by managers before even consulting developers about the complexity of work to be done.

Yes, imagine air travel wasrun like that: "The plane must be ready by December 1st!"

Proper safety checks wouldn't let the plane leave the ground. Delays in that critical state are inconvenient, but you accept them because the alternative is not acceptable.

We should treat software in exactly the same way, It's ready when it's ready.

The issue is the illusion of control. A bad CEO will measure the performance of his CTO by productivity alone. A good CEO will measure the CTO's output by consistently increasing quality.

Yes, imagine air travel was run without deadlines.

You've booked a flight on dec 1 at 3pm. You check in, sit at the gate. At 2:40pm you are informed that, sorry, the plane isn't actually there yet. It's still on route. We'll fly at 7pm instead. You sit and wait. At 6:45pm you are informed that the plane is there, but the airport is out of fuel. More fuel will be there tomorrow. Rescheduled for next morning at 8am. You wait. At 7:40am next morning you are informed that the pilots are not awake yet. They had a long day yesterday, then went for some drinks, they just had to sleep in today. Rescheduled to 11am. At 10:30am somebody tells you that, well, things are in place but ATC went to a team building event, all flights grounded, but will be back at 4pm. You finally lift off, 25 hours late.

Entirely preventable had a deadline be set and all necessary components be scheduled correctly to meet that deadline.

Deadlines serve a purpose beyond coersion. There is misuse, but if you widen your horizon then you may realize that not all of it is.

Obviously the OP is talking about developing and manufacturing a plane, not flying it. Your example is a schedule, not a deadline.

You're not describing a "creative" situation where you are building something new.

If you had to reexplore and reinvent flight routes every single time, yes deadline in that scenario would also become meaningless as you'd have no idea what lies ahead each time. It would be the same as setting a deadline on how long Columbus should take to reach India.

It is very rare that we actually work on something truly novel, and it’s even rarer that the majority of the task/project is novel. It’s really not that hard to identify something “reasonable” for most tasks, once you’ve broken it down. The pieces that are actually novel — you make an estimate to produce an estimate (how much work do you need to do before you get a handle over it?)

Of course, the further you go out, the more your error margins (and the less others naturally rely on your estimate, and the more likely you say something generic like coming soon in 2025)

But this notion that it’s all creativity born of the ether, as if you’re sitting around waiting for eureka to suddenly strike is complete bullshit.

There is the issue that external resources will latch onto your vague estimates like it’s the word of god, and try to hold you accountable to unreasonable degree, but that has nothing to do with your planning. Usual solution there is to figure out what feels reasonable, and then double it again for your boss — and double it again for the client (which you’ll probably lose a bit to negotiation). There’s also the issue that a single heisenbug can take stupid amounts of time to resolve… but that’s why you doubled up — you keep buffer for that kind of thing.

The vast majority of any project is just plumbing — creative or not.

You are of course right, and that’s the basis of SCRUM like thinking.

The point I’d still raise is that very few organization are OK with actually going the full length to reduce the error margin to what they want to tolerate (they still end up eating the costs associated with the actual execution time, of course)

For instance: you integrate a new API from a new vendor, and a request is made on a time estimate. It’s probably a very bland task with no crazy thinks to do, except you have no idea what surprises you might get actually running the API. What if the vendor din’t account for one of your use case for instance ? (let’s say they round money amounts to the nearest cent while your business requires round ups everywhere instead)

The safeguard against that risk is to either: fully run the API beforehand and cover all your use cases, or document every single requirement and run them through your vendor. If you’re not a bank nor the NASA, you probably won’t be allowed to do that before giving an estimate that will set a deadline.

It’s to me one of the reason why outside I put “creative” in quotes, as the problems we’re trying to solve don’t need to be complex, unexpected is sufficient. And ‘deadlines’ are more probably more ‘guidelines’ as most orgs don’t really care to secure them.

> It is very rare that we actually work on something truly novel

I'm working on something truly novel to me every day. The fact that it's novel to me is enough to make any wishful planning arbitrary.

Unless you are really bleading edge, say mRNA vaccines, there should be someone with experience in what you are doing. Even for the bleading edge stuff, people have relevant experience to build upon.

Sure, there are people who are experienced in the areas that are novel to me. But, engaging them to the project may not turn out to be a better alternative (in terms of all kinds of variables: time, money, communication and coordination overhead, etc.) than my learning the subject.

Teams that subscribe to the agile methodology have a tendency to churn out ad hoc systems because there is not time for due diligence. The end result is ad hoc things built on ad hoc things. There is no limit to the learning curve. The knowledge doesn't transfer in the smoothest way because (a) there is no time for an engineer to perform due diligence, and (b) engineers are interchangeable cogs that flip high tech burgers based on orders from the Jira board.

The amount of brain waste caused by agile is immense. So many minds toiling away, trying to pick apart some long lost engineer's cleverisms and build something mundane on top of them.

> You're not describing a "creative" situation where you are building something new.

That's true. But the article is not titled "Why deadlines are pointless for creative processes." It's arguing that deadlines are pointless. Always. That's oversimplifying at best, click-baiting at worst.

I'd argue that even in a creative process, if you add enough of a safety margin on top of a conservative estimate, then a deadline can be expected to be met with reasonable confidence. This is absolutely necessary for doing business. "We release when it's ready" is a workable strategy when there are no obligations, but claiming that this always works in all other contexts is just not honestly considering other contexts.

>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".

> You check in, sit at the gate. At 2:40pm you are informed that, sorry, the plane isn't actually there yet. It's still on route.

This is pretty much what regularly happens.

You are talking about a schedule not deadlines. Of course schedules are required, but safety is the concern.

The pilot turns up drunk, she turns up on time, but drunk. Do we stick to the flight deadline?

> You are talking about a schedule not deadlines.

A schedule is a set of events happening at certain time, right? They have to happen at that time since there is a contractual agreement on them happening at that time, and if they don't happen at that previously-agreed-upon time, then there will be negative consequences. That's exactly what a deadline is.

My schedule for today says that I am to meet a certain customer today at 3pm. We have a contract with them that stipulates this. In order to be there at 3pm I need to get the train at 2:10pm and for that I need to be done showering latest at 2pm. I can't make it otherwise. 2pm is a deadline for me. Bad things will happen if I don't make it. I can't justsay, oh well, quality just wasn't enough. I had enough time to plan ahead and be in the shower on time.

I was on a flight like that - literally. Flying to Argentina, via Chile, from NYC.

Plane was supposed to leave at 2:00 PM. We all got here at 10:00 AM for the long check-in. Got word the plane would be late, so 3:00 PM. Then 4, then 5, then 7, then 9:00 PM, finally took off at about 9:30 PM, over 7 hours late.

It turned out that this was because the incoming flight on this airplane was a 1st class-only flight, and the airline had failed to allocate time in the schedule to swap out the seats so there would be enough for the regular-class passengers. On arriving in Santiago, we had of course missed our connection. So, had to be put up overnight for a flight out the next day. Basically arriving a day late.

Had lots of other examples, but indeed, deadlines make no difference whatsoever when the plan fails to match the reality.

It is the plan that is important, not the deadline.

I can also say from developing software for several major events that occurred at specific times — there is no slipping of the date, ready or not — that the process is much more oriented towards managing the balance of development and scope than all-nighters. Sure, there's a few of those, but the overall key to the making the deadline is having a manager who can keep pruning the tree and keeping distractions at bay.

this is exactly how air travel works though. if your incoming flight is delayed you get delayed regardless of what the schedule says. setting a deadline does nothing to address the lack of a plane. the plane arrives when the plane arrives

I think you provided an example for the exact opposite of what you wanted to express.

An airplane better arrive before running out of fuel. Somewhere, at least. That's a real deadline. You can't negotiate yourself out of that one. Empty tank == you will land NOW. One way or the other. So this is all full of safety margins, extra fuel, alternates, etc etc. But there is a time span which every flight will not exceed. Guaranteed. The pilots better be prepared for this, otherwise they die.

A flight is usually structured with many "lesser" deadlines. Latest time to abort takeoff. Latest time to turn to an alternate. Latest time for this-or-that to make for a safe landing. Glide slope. Localizer. The whole procedure to land a plane is full of deadlines. If you miss one, you execute a go around. Until you are out of fuel, then you better nail it.

So, no. Deadlines are not pointless. They can make the difference between living and not living.

So air travel pose covid?

> Yes, imagine air travel wasrun like that:

Erm, except air travel DOES run like that.

Deadlines are at the very core of air travel.

The crew agree on a flight plan and file it.

If the aircraft goes AWOL and does not arrive at its plan waypoints by time + buffer, then all hell breaks loose.

There are also deadlines for landing slots, deadlines for flight closing, deadlines for this, that and everything else....

Aviation without adherence to deadlines would not work.

As for maintanance, airlines keep a ready stock of parts and have relationships with maintenance organisations at all major airports. There are also regular scheduled inspections. An aircraft on the ground is a loss making asset, it is in the airline's best interest to maintain the to flightworthy standards at all times.

Your point is very valid to the above but I'd like to fix GP's example. The distinction here is that what's being discussed is more about deadlines that are built around systems that are already deemed stable and mature, already went through all these processes and now have a fairly stable level of uncertainty and data surrounding it they can work with.

Imagine more if the airline promised a flight would be ready using a brand new plane that was just now being designed out or at some stage in development someone unknowledgable felt comfortable to start making promises about timelines and even extrapolating out production. New plane designs and manufacturering take years and years sometimes. Have all sorts of delays, have safety issues that require them to redesign things later and so on. You don't see a lot of new plane designs you see the same known things used over and over.

It's one thing to make forecasts around fairly well known, established, and mature systems and processes, it's an entirely different beast doing so around less known systems and processes. The vast majority of software engineering and development is done around something new or different that has little contextual reference. If you do have reference then you're rebuilding the same things using the same pattern and it won't be long until libraries, frameworks, systems, processes, etc. emerges to automate that at which point your time shifts to the new things you need to automate which haven't been automated or done yet (again, otherwise you'd just leverage the prior work).

Planning to make a site using something like say Django vs building a new framework with different features like Django are very very different and a lot of development is trying to do something unique and new which means high uncertainty.

In that case deadlines are useful because you have so many people depending on you that you don't know which or how many of them have real dead lines. That isn't as common in software I think?

But needing a new working iOS by ship time for the next phone? That is a pretty hard deadline, and why apple doesn't use agile. They say agile doesn't support synchronous hardware/software releases.

The problem is when I bsupport multiple efforts, some with deadlines and aome without, the ones with deadlines always get "done in a minute" descoped so that I don't starve an ongoing que as is described here.

I think it's easy to argue that all those things are what the author would call preëmption points

Having a deadline (plane must be ready by December 1st) and missing the deadline because of quality issues (plane was not air-worthy by December 1st so we can't let it fly) are not mutually exclusive. Deadlines do not mean that quality has to be sacrificed.

Even for the most objective deadlines (contractual obligations, holiday promotions), there are alternatives to releasing a low quality product, and the pros and cons must be measured. Does paying damages for failing to live up to the contract beat the reputational (or even legal) damage of releasing a low quality product that technically meets contractual obligations? Then a responsible company will pay those damages. Does releasing the product on time for Christmas, even with the level of bugs known and/or potential unknown ones, gain you more good will than delaying it by a few weeks? Then uphold the deadline and promise a patch soon after.

The deadline is an arbitrary guess, based on experience of when something will be ready. Of course delivery dates are important, quality is also important.

The author I think could phrase the argument better by saying a delivery date (something that is promised, based on quality) is more useful than a deadline (something demanded, regardless of quality).

Delivery dates do not preclude working hard and bring prudent, but they are not hard stops. Rather they are good estimations that can and often do shift.

Sales team needs that thing by December 1st? Don't ask for it on November 29th. Put leeway into the model by giving time for the delivery date to be missed. It's called contingency.

But, depends on your philosophy - move fast and break things,or deliver consistent quality code.

Deadlines and delivery dates are the same concept.

The alternative the article proposes is entirely different - it proposes a work queue system, where the team is always working on the most important current task(s), and where every task that is taking longer than some pre-determined number of days is re-evaluated to make sure it is still as important as believed.

> Sales team needs that thing by December 1st? Don't ask for it on November 29th. Put leeway into the model by giving time for the delivery date to be missed. It's called contingency.

That's not how the article thinks. Instead, it views it as "sales team needs some task done by some date? move it to the top of the work queue as soon as you know about it and the team will finish it as fast as possible anyway". Will that be before or after December 1st? No one knows, no one cares: it will be done as soon as possible.

For inherently fixed scoped tasks (say, "our product must ask users for consent before collecting data"), this can work fairly well. But I don't think it is realistic for the vast majority of work, which is far more vague in terms of scope.

Heck, sounds a lot like my current place! A lot of talk about "critical path", agile and sprints everywhere, even on the hardware development side, a lot or reprioritization going on. And guess what, all prmosed dates and schedules are constantly missed. Mind you, that the whole place is living of investor money and needs more that rather soon.

>> Yes, imagine air travel wasrun like that: "The plane must be ready by December 1st!"

But that is how it is done??

The delivery date of an airplane and it's flight schedule are two completely different things.

The delivery date is an estimate and the date can shift until the plane is safe to fly. The deadline for delivery is not a true deadline and the factory will only work to its safe production limit to deliver the plane.

A bad practice would be to just put the plane out on the tarmac, regardless of state.

It works to the safe productivity limit of the factory, not the arbitrary demand of the customer.

Customer’s demands are rarely arbitrary. Time is money and there are typically many moving parts to any corporate strategy.

For example, if the customer’s plane isn’t delivered on the agreed upon date, you now have pilots, flight attendants, mechanics, etc. that need to be paid for no work, or let go and new hires made / trained at a later date, which is expensive. It’s also lost revenue and market opportunity.

There’s also the potential that the customer cancels their order and buys a different plane from a different manufacturer.

Agreed you can’t put out a plane that’s not safe, but you can pay overtime, or shift resources between projects, etc., to produce a safe plane and try to deliver on time and limit the above negative effects on the customer.

In general, if you ask someone when they want something done by, they usually say “as soon as possible”, not because it’s arbitrary but because there’s typically real world value in completing a task / gaining access to an asset sooner rather than later.

Oh dear, do you have any idea what, say, Emirates will do to Boeing and Airbus if the promised delivery date is missed? And how airplanes are built and delivered? Hint, delivery dates are not estimates and proposals that might be met, or maybe wont.

And what makes you think planes don't have to safe for flight, with controls and sign offs, before take of?

> Oh dear, do you have any idea what, say, Emirates will do to Boeing and Airbus if the promised delivery date is missed? And how airplanes are built and delivered? Hint, delivery dates are not estimates and proposals that might be met, or maybe wont.

Both Boeing and Airbus have missed a bunch of delivery dates this year and will continue to do so. For some of them they're blaming regulatory approval. Guess what, it happens, life goes on, people in that industry can at least recognise that it's better than flying a plane that hasn't been approved.

> And what makes you think planes don't have to safe for flight, with controls and sign offs, before take of?

They do, and again the point is: what happens if the plane isn't ready? It doesn't fly until it is. They don't ignore the checks because they have a deadline.

Missing a deadline doesn't mean that deadlines are pointless. And yes, Airbus and Boeing missed those. Guess what, they had to pay contractual penalties.

You want to do creative work without deadlines and real world consequences for missing those? Become an artist, a rich one preferably because sponsors and exhibitions are a thing in the art world, too.

Depending on the contract, missed deadlines usually have penalties. There is a reason for deadlines, especially for complicated projects. The reason being other people have to plan their time to make use of their available resources profitably.

> The delivery date is an estimate and the date can shift until the plane is safe to fly. The deadline for delivery is not a true deadline and the factory will only work to its safe production limit to deliver the plane.

Boeing and Airbus tend to hit their deadlines for supplying planes all the time. Where is this hypothetical universe where they refuse to give a deadline, or refuse to meet it?

It is. “The plane in Chicago now will be ready to take off from Phoenix at 7:45 AM tomorrow.

You build process around things to make them happen. Nobody is waiting for some artisanal process to magically produce a plane. There’s maintenance and cleaning schedules, crew schedules, etc. The preflight check is a final verification.

A good CEO measures the performance of the CIO by availability and quality of services. The CIO looks downstream to ensure that the operations teams have appropriate processes in place.

Boeing having missed its deadlines for a decade doesn’t mean aviation doesn’t have one. If anything, Boeing exemplifies the flaw in this philosophy.

Time is a factor in almost every human endeavour. Either internal or external motivation to get something done "quickly" is often needed. Otherwise, we start attempting to optimize all variables instead of the ones that actually matter.

The problem is external artificial pressure almost never helps.

If you are two parties to some project (e.g. a software product pr feature that should launch time with an investment or business change) that agree to a date, it starts off arbitrary. Everyone wants it as soon as possible, but exactly when is arbitrary.

However once you agreed to it it's no longer arbitrary. It's the agreement. That other part of the business that changes their accounting software or replaces the machine on the factory floor has agreed with you to ship by that date.

Arbitrary but committed to in a sense that would be detrimental to some other part of the business if you miss it. That's not quite completely arbitrary.

I would say about 85% of deadlines are just pointless and 15% do actually matter and it is very crucial to recognise which deadlines do matter.

I always insist that arbitrary deadlines be called “target dates” to try to prevent this exact perception when there is a real deadline.

In our case, there's a marketing campaign planned, customers invited to a conference where the new version will be announced, and so on. There are people depending on the release date they've been given.

> But in most cases when I asked managers about the reason behind the deadline, the answer was something like "oh,I promised this team/director we'll do it by then". When I dug deeper to see what happens if we miss the deadline, it appeared the said team would be just fine, there were no real life consequences, just that they wanted to finish their part of work by certain time, and they depended on us.

That sounds like evidence for deadlines not being pointless.

Someone, somewhere, depended on a certain ETA. That's a deadline, regardless whether you think that there are no consequences for missing it.

Whenever I hear this I chuckle.

Say you book a wedding with your fiance and on the week prior ask her if there's any reason behind the wedding date being when it is. And if you dig deeper you'll see no "real life consequences" will happen to either one if you miss it, either, but I'm guessing she walks over missing this "arbitrary date".

The fact that nobody dies or a regulatory body doesn't fine you straight away, or as you put it, if it's "arbitrary" doesn't mean much. The industry your whole company is in, at some point was also an arbitrary choice by whoever started it. We're humans, pretty much everything we decide to do is arbitrary.

> The fact that nobody dies or a regulatory body doesn't fine you straight away, or as you put it, if it's "arbitrary" doesn't mean much. The industry your whole company is in, at some point was also an arbitrary choice by whoever started it. We're humans, pretty much everything we decide to do is arbitrary.

The problem is when you treat deadlines as something very important and absolutely essential to meet, especially when the dates have just been made up, without even having the full picture of what must be developed, way back.

That's how you get crunching and people having to sleep in the office. That's how you get working until 1 AM just to ship something so the system can go into prod on this made up arbitrary date. People who do this sacrifice their own wellbeing and those who don't no longer seem like team players, leading to a culture that's unhealthy or toxic.

This is especially noticeable in the video game industry, where it's become a widespread problem - even by outsourcing to lower paid developers and getting a bigger workforce as the result, the deadlines for game releases are still unreasonable and you ship buggy games (e.g. Cyberpunk 2077) on the backs of delusional young people who work too much and burn themselves out.

In the company I work at there's a rule that if you're caught working nights or weekends you're getting crap over it, you never get rewarded for "something cool you did last sunday" or anything like that, and there's no crunch time.

If you put those conditions in place, are you still against deadlines? Because we've tried not having them, and collectively agreed it's worse. A team that has no deadlines performs worse than a team that sets deadlines for itself. You might've noticed this in your personal life with your own motivation.

For anyone that doesn't want to ignore the fact that humans are way more productive with deadlines than without, the question is what do you do when it looks like you're going to miss the deadline, so that this balance is a healthy one between motivation and doesn't go into overwork. In this mode of operation "meeting the deadline" means cutting scope instead of working more hours. It means pulling another team into the project, it means leadership being OK with cutting scope, etc.

But pretending like we're all intrinsically motivated and deadlines are harmful is papering over the fact that what's harmful is how you deal with failed deadlines, not the fact that you're aiming your work to be completed at a certain date.

I’m sure you’d usually get very reasonable answers when asking about the rationale behind a set wedding date. For one, engaged couples are probably looking forward to being married, so there’s value in having it as soon as possible. You’ll also probably hear about it being in the right season, the venue being available, enough money saved up, etc.

In a business, a deadline should have valid a business case, one that’s not arbitrary - does it help improve the bottom line, or not? One senior manager thinking he will look good to the C-suite by having it done by a certain time probably doesn’t. Agreeing on a rough date with an external client, who have their own considerations to take into account, probably does.

I don't think the comparison is valid.

The people setting the wedding dates are the fiances, who are the ones organizing it and are also the main recipients. In that case they are both the vendor and customer, it is pretty much like a DIY situation, even if there is some outsourcing involved.

Now I won't say deadlines are bad, but they shouldn't be set and promised without first getting a careful estimation, which is what the parent comment is criticizing.

- deadline set randomly or by gut feeling of a manager = bad (more often than not)

- deadline set after careful estimation of resources involved, their own estimations and possibly the number of side projects that might have to be rescoped/paused for that purpose = good

Also: wedding dates are often set far out in the future. It is never: 2 weeks from now we MUST have the wedding.

Not sure what's your point. Yes, deadlines are arbitrary just as most things are. That most things are doesn't change a thing about correct estimates being practically impossible and deadlines harmful.

That is a very interesting example because in my (Southeast Asia) country & culture, a missed wedding date will have a real & huge financial consequence.

I think a good distinction is what happens after the deadline. The wedding won't keep getting planned after the wedding date. Most software keeps being developed after a deadline. But I guess there's software that is "one shot" as well? Like a visualization software to show/analyze the election results as they progress during election day.

It’s not that deadlines don’t exist (for some business reason), it’s just that trying to have both a deadline and a set of completed features is contradictory (if you want something that works well).

You can set out to have a set of features, and you can have a deadline, but thinking all the features will be completed (and completed well), on that day has never worked (in my experience). You just wind up with rush hacked garbage towards the end.

This is what I’ve done successfully for years now (when I am not forced by a PM to do agile): https://concentric.works/

This is what agile actually wants you to do.

You can have a deadline but no fixed scope, this what CI/CD is for. So when deadline day happens what you have is already released.

Or you can have fixed scope but no deadline.

Or you can have fixed scope & deadline, then pad things to hedge risks that might pop out.

Agile prefers the first.

>This is what agile actually wants you to do.

And almost never does because it's designed in a way that's easy to abuse. Instead you often see dynamic ever-changing scope, dynamic ever tightening deadlines, and no margins for risk. Everything is on fire always and you just chase the fires around with your dev teams to put out fires, crack whips, and ask why features are behind schedule. It's madness in much of the industry.

> This is what agile actually wants you to do.

Maybe, but I am not sure, and that’s not the way I’ve ever seen it done.

The only way I’ve ever seen agile done is “waterfall with two week sprints”. Large wireframes of an entire application which is “unreleasable” until the end.

Sure it compiles during each sprint, but it’s not a releasable product at any stage (until the mad rush at the end when all the negotiations and trade offs begin)

That was a good read, thanks. Similar in principles to ShapeUp, which I think is one of possible implementations of Concentric. I like that it's defined loosely and you can use it as a basis for process that will fit your team.

"then the software development output is a gating feature for real-world contractual obligations"

Cool, I hope that whoever agreed to these obligations knew full well that they were taking a gamble and are prepared to deal with the consequences of the gamble not playing out.

A complex software project is already a gamble. It may drag on for years even after the most pessimistic time estimate. it may totally fail (the outcome which is rarely taken into account). Drawing an arbitrary deadline on top of it just makes it a more risky gamble.

> Estimation, planning, and progress tracking are difficult skills that must be learned, but they’re not impossible.

Judging by the constant stream of overdue and overbudget projects in more traditional businesses like construction, which are significantly stricter in terms of regulation, planning and have been around forever compared to software engineering, I'm not convinced accurate deadlines are possible.

Depends on the nature of the work - I recently did a gig at a civil design engineering firm and multiple projects came in at or under budget and on deadline.

We’re there some serious overtime crunch periods on a couple of them? Yes, but for a multimillion dollar project with expiring Federal funds, it was achieved as set forth.

I think we tend to hear more about the failures than the successes - the Omni hotels in Houston and Dallas built with bond funds were repaid years earlier than mandated because they were successful, for instance.

Estimates aren’t necessarily accurate just because they end up being close to reality - that could just be chance. The estimate for a project that came in substantially under budget was just as wrong as one that came in substantially over, it’s just easier to live with. If all estimates are wild-ass guesses, then some will come in on time and budget, some will undershoot and some will overshoot.

I do believe that estimates, even for complex projects, are useful and can be fairly accurate, and in a lot of circumstances they can be used as the basis for deadlines, with certain considerations.

If "achieving" your estimate included a lot of crunch, your estimate was bad. A lot of poor estimation externalizes it's error to those trying to meet the estimate. Long hours, weekends, etc. over months while pretending the work fit on a nice paced 40 hour week with breaks is not a good estimate. Chances are, there's probably a lot of corner cutting in the final product as well, because your requirement set and associated deadline was the priority vs having a quality product delivered.

When your software is a piece of a much larger, expensive real-world project, deadlines are not pointless.

Imagine, for instance, writing software for an interplanetary probe with a short launch window.

Pretty different from writing the 'Yo' app.

> If you go to the other end of the spectrum and talk to engineers who work in industries where target dates are critical you’ll discover a lot of people who are very good at breaking down projects and accurately estimating dates without relying on crunch time to get things done.

I am yet to see this done well, though hearing that it's apparently possibly has me cautiously optimistic.

In my experience so far, however, I've mostly seen incomplete requirements (one could argue that a perfectly accurate spec would be no different from executable code, the end product itself), changing requirements, difficulties in estimating the impact of needing to migrate old data or accommodate/refactor old logic, little proper estimation of testing overhead, the impossibility to predict how long working with external services and integrating with them would take, especially when cross coordination with another team is necessary, the impossibility to predict what might break in regression testing or additional edge cases that might be discovered, as well as the greater impact of needing to utilize particular tech stacks (e.g. Kubernetes with a particular service mesh) due to external requirements.

It's gotten to the point where I feel like adding a new form to any given application might take anywhere from 2 hours to 2 weeks, depending on what's going on in it (e.g. a well architected and simple monolith with onboarding guides and commented code vs microservices with little to no documentation, to serve as examples of different orders of magnitude of complexity).

Estimations feel like just making stuff up on the go at best and like something actively harmful (being urged to make promises that are going to be false a lot of the time) at worst.

The only way to do them would be not to do them - instead have some software look at the issue request and say: "Okay, you have X requirements of the following type: ..., after analyzing this project's issue history and time tracking across 5432 issues, it would appear that this issue would take between 4.2 and 7.3 days to resolve."

To me it seems that if you need to be able to give accurate estimations, you'd also need a very predictable and boring tech stack across many if not all of your projects, which doesn't seem feasible in web dev, given how fast everything seems to progress and given how much CV padding one must do to remain hireable (instead of, say, using jQuery in 2022).

Correct when true. But if talking about all deadlines, you can sort them by category. One that I especially don’t like are populistic deadlines, when team burnout is used to: impress or brag before someone, get some quick results only to spend few weeks before even looking into it, set out of a thin air in a project of an RnD nature. Deadline is not only a planning instrument, it is also a force that allows to tick the box regardless of a true state. You cannot always expect them to be used in a sensible way, because other departments and heads suck as much as you do, or more, if they are further from physical/informational reality. Tight budget means tight planning, but it might also mean that your chiefs are simply underperforming.

Working on the edge of bankruptcy for years, never seen my “push hard this week (or: this sunday) it’s important to us” taken as important or used right away. I even learned to detect with high probability when the rush is based on cocaine and can be safely ignored.

This is not a rebuttal (I agree that deadlines are useful), it’s just the back side of this shiny coin of “effective management”.

The fact that the deadline is not “arbitrary”, because it is a contractual obligation, doesn't automatically make the contractual obligation feasible. The reasoning behind signing the contract could still be based on “arbitrary” reasons, wishful thinking, political agenda, etc. Putting project constraints on paper doesn't mean that the project will meet those constraints.

A lot of business leadership handwave this away and I've seen some claim the only way to remain competitive was to go this insanely aggressive towards the target in some way: low budget, short timeline, "optimistic" feature sets, etc. It's especially common in larger businesses with layers of middle management that aren't held accountable and pass their poor decision making down, often making it difficult to identify the real problem they are to the organization. Even in small orgs, if you need to make unrealistic promises to compete, you shouldn't be competing and should refocus your business, your current business plan is flawed and its not inherently your employees fault that they can't deliver as efficiently against businesses that focus on some niche and have done so over decades or benefit from economies of scale and fat margins to pad such projects they can afford to operate at a loss.

>A lot of business leadership handwave this away and I've seen some claim the only way to remain competitive was to go this insanely aggressive towards the target in some way: low budget, short timeline, "optimistic" feature sets, etc.

There's an old saw that goes something like, "fast, cheap, good. Pick two."

I've found that to be true over and over again.

All three options can be useful depending on whatever it is that's being worked on.

Many of the complaints in this discussion about setting deadlines seems to be that not enough resources are being allocated to meet the "fast and good" selection. Which, of course leads to an end result of "fast and cheap," which isn't the goal.

The main argument seems to be that "cheap and good" is better than "fast and cheap" because there aren't enough resources allocated to achieve "fast and good."

The solution, of course, isn't to eschew deadlines, but rather to determine the work required and make a decision about how the work should be done (with the above being a simple-minded way of describing that 'how').

It seems like deadlines become an issue when those setting such deadlines are focused on the "fast and cheap" pair, while the folks actually doing the work want "good" to be part of that pairing.

As someone who has worked both in environments which focus on minimizing time and cost when bidding for work, and in those where estimates realistically reflect the time and cost of completing the work, I find the latter to be much more effective.

The former is generally a shit show where no one is happy. The client either doesn't get what they need, or it's going to cost a whole bunch more than they were told, and those actually doing the work are pressed to work harder and faster because the client is pissed off.

And the business generally loses in the medium to long term as well, as they're unlikely to get repeat business and certainly won't get referrals from that client.

When good estimates are provided and the appropriate resources applied, projects often go much more smoothly and everyone wins -- over the short, medium and long term.

Obviously this requires good planning and a strong understanding of the goals and requirements and translating those into reasonably accurate estimates. Those (as others on this thread pointed out) are skills that can be learned.

Sadly, those skills seem to be in short supply. And more's the pity.

Edit: Clarified my prose.

All the recent projects I've been on have been shit shows, and I put it down to Agile, MVP, and inappropriate tools like Jira and Miro being used to manage projects with pretty diagrams and no depth or proper interdependency mapping.

I'd go for an old school MS project wielding project manager any day of the week.

Even his first metaphor falls down:

> You can’t simply start training today and run a half marathon tomorrow, for example. You can, however, create a system in which you consistently increase the number of miles you run.

The marathon will be on a specific day, ie a deadline. If you haven't finished your training before the day of the marathon, you fail.

As someone who has run many half marathons, one marathon and followed several training programs: no, that is not what happens. If you have not finished your training the only thing which happens is that you will probably run slower than you would have if you had finished your training. A common advice is to not follow the plan slavishly because that way there is only injury and burnout.

So, yes, races are deadlines but not deadlines you can rush towards because then your body will break and then you will fail the race for real. You still need to slowly and consistently build up your body just like if there was no deadline at all. It is much better to not have finished your training than to be injured.

> You can, however, create a system in which you consistently increase the number of miles you run.

This is indeed how you become a fast runner and how most training plans work, except they often peak at a mileage most people do not want to sustain to top the form right before the race.

Can you elaborate? I couldn't understand how the metaphor fell down. How does the existence of a deadline help me achieve it?

Creating "a system in which you consistently increase the number of miles you run" is pointless if it doesn't get you to the point where you can run the marathon on the day that it happens.

How long you have until the marathon would determine what kind of training schedule (system) you create.

Yes and no. Having more time gives you more flexibility in how to plan it so you can for example either reduce injury risk or aim at running the race at a higher pace. But it is not like you can rush it beyond a certain level.

I feel one of your misconceptions is that running a marathon (or a half as in the article) is something binary. A lot of people could just go out and run a half marathon tomorrow if they were forced to. The injury risk would be high and they would feel miserable, but they would make it. A full marathon requires much more training but all marathon training programs I have seen are overkill if the goal is just to complete the race. They are instead aimed at either making people complete it at a certain pace or complete the race while being able to enjoy it. If you have a lack of time to train you can sacrifice pace/enjoyment. Rushing the training on the other hand is stupid.

So for marathon training the deadline is in the form of a hard cutoff where you have to decide if you are satisfied with that little training or if you want to wait until a later race. It is more like a release train which only happens a couple of times per year.

Edit: Sorry for the rant, my real point is actually that you are encouraged to change your training plan on the fly to adapt to real life events and that while the race is a deadline it is very unclear what will be delivered at it until you get pretty close to it. Will it be a 3:30 marathon or a 3:15 one? Unless you have sponsors nobody will get angry at you for not delivering what you had planned to.

> if it doesn't get you to the point where you can run the marathon on the day that it happens.

Doesn't the same logic apply to the training system that we created based on time until the marathon? Does the existence of a deadline guarantee success of a training system?

And, doesn't any training system increase the number of miles consistently? Because, if I am to run 26 miles, any training regime should make me able to run 5 before 10, 10 before 26.

This is a straw man that the article argues against. I don't think it is a common belief that deadlines make you more productive. Deadlines exist because that is reality.

The marathon happens on a specific day. You can train however you want, but if you want to run the marathon then you need to be ready on the day of the marathon. Deadlines exist.

I worked in the actual, physical industry programming parts of assembly lines. Yes, such estimates are asked for and given. And yes, they are completely bollocks. So bollocks in fact, that when you arrive on project, the estimated time you gave, was already used up by other entitys like construction, eltronic engineering and various logistic problems.

One can only estimate things done before. By the same person. One the exact same machine. In the exact same circumstances. And even then, the % savings of only replication after every known unknown has been eliminated, is mostly guesswork.

The truth is also, that most planers constantly overrun there own project planning deadlines and the promises of their projeccts. But hey, the pope forgives himself, thats the easy part.

I wish the likes of you would for just one year walk in those shoes on whose toes you usually step to apply pressure. And no, repeatetly asking for a better timeline on nailing a pudding to a wall, does not get you closer to reality. It only gives you a metric on how fast somebody insufferable gets to hear whatever he wants to hear to dissappear. And your planning and all the deadlines, are not even part of the after project renegotiations usually, were whats actually was demanded in the final form and all between forms - and what was missing is broken down into kharma and money.

For constant change is even in physical projects, when things do not work out. Usually the planners are then "taken off project cause they are needed elsewhere", aka the grownup need to find a solution and they need to find it fast and efficient, without additional barking waking the real mean dogs.

> It’s always fascinating to read these anti-deadline articles that assume deadlines are arbitrary things that exist for no reason.

The one thing I hate more than that, is articles such as this one that waffle on for eternity using pseudo-science.

For example, what do all the pretty graphs and paragraphs of waffle about coin tosses have to do with the price of eggs ? Its basically space padding that doesn't add anything to the argument they are trying to make.

One cause of this is that we as a community have not properly shouldered the responsibility to teach good estimation skills to new engineers. It is a skill I likely now need to be able to teach —- though I still need to learn it myself.

I am one of these developers.

Let me give you an example of a real life consequences deadline where the project is state financed with money provided by EU, the end of the current political party term is nearing and the money is available on the premise that the project is finished successfully. "Is done" is actually approved by a third party inspector who not necceseraly works in your or the project's best interest. The project done by several separate subcontractors and if fails the political party looses faces before elections and if it fails to deliver the money provided by EU won't ever arrive and you won't get a dime. But you will pay the consequences of a failed contract.

I was an IT pm/ba/architect for one of the subcontractors. This project gave third of our annual income. Should we miss it it has the chance to bankrupt the company and as a bonus you have an angry political party against you.

Go, plan it, estimate it, deliver it on time.

I agree that every deadline is artifical and negotiable but EU financial support deadline is a fuckin hard deadline because you cannot possibly have the necessary network and position to initiate any kind of change.

I think some developers live in some strange land where they either don’t have enough to do or have the freedom to navel gaze at these things.

From my POV, I’ve been in the tech biz for a long time and never had an issue with managing deadlines. Sometimes they need to slip, but overall, we seem to middle through.

Deadlines are real, but estimates are very inaccurate. The best you can do prioritise the important features. Then what gets released is what you have at the time.

If you want to plan for real hard deadline with a fixed scope, you need to be giving it A LOT of time to account for unknowns and feedback cycles.

I've worked in environments like you say, all they do is massively pad estimates. That's not accurate estimates, that's just hedging risk. Estimates should be taken with a pinch salt, then risk should be hedged. But they're separate things. You can't just massively hedge risk and say estimates are accurate. In fact that's more of an admission they're inaccurate.

It shows they have never worked in a regulated industry like banking. FRTB, MIFID 2, PRIIPS RTS etc etc all have/had fixed deadlines and sanctions against the company for non-compliance.

Or heard the term "monthly / quarterly / year end closure in places they worked at. Or faced contractual penalties for late deliveries. Or faced some deadlines caused by investors / burn rate, or any number of reasons. Or, the other way round, had to wait for someone to finish things they needed or wanted, e.g. a plumber showing up at their place to repair a leak. People refusing to commit and see those commitments through are such a pain to work with.

Agreed. It's a naive view.

I'm of the opposite view. I worked with many SWE teams, and estimation was, in every case, a waste of time. Deadlines and estimation don't work well for building software, especially web applications. In my experience, what works is working on lean features with a small scope, fast iteration with continuous deployment to gather rapid feedback, and constantly changing the project's scope and direction.

I think what you say and he says are not that different: he argues that the concept of deadlines is really pressure which is also what being not cash-rich is about, you have limited resources, therefore you have pressure to make the most out of them.

So deadlines can be a lazy, dumb or crude way of pressure and may not have the intended effect. Surfacing the real reasons and dealing with them directly might be more effective.

> Estimation, planning, and progress tracking are difficult skills that must be learned, but they’re not impossible

Planning how long something is going to take when you're completely in control of your own schedule is difficult but not impossible. Planning how long something is going to take when you are also expected to drop everything for every meeting or production problem that comes up is impossible.

Your explanation sound reasonable, except for the fact that you seem to mix estimates and deadlines together. I don't trust the planning of anyone how doesn't make a big distinction between estimates and deadlines.

So I would like to know how your development environment deals with this.

> In that case, target dates must be carefully forecasted and estimates must be performed with great care and detain.

That is exactly what many software engineers accuse of quite some project managers not to do.

I'm a type of person that can't live without deadline. If my mom doesn't say "today" in her order, I'd forget to do it.

Do you have any specific resources to recommend re: project estimates?

funny given that only a month ago he was expounding the benefits of "Talk To Your Customers" [1] aka "Agile", which is essential artificially and programmatically governing your day via deadlines.

[1] https://lucasfcosta.com/2022/08/03/talk-to-your-customers.ht...

The TFA still talks about talking to one's customers, so this doesn't really contradict it.

> If your team can’t ship without deadlines, the lack of deadlines is not the problem. Your team’s careless attitude about customer feedback is.

> When teams obsess about customer feedback, they ship as early as possible so that they can listen to their customers.

> For customer-centric teams, artificial deadlines are useless because the only “deadline” that matters already exists: “as soon as possible, as long as it’s valuable.”

You're choosing to conflate listening to customer feedback with Agile.

Yup this you ship as fast and often as possible and then listen customer feedback. Deadlines traditional sense are working against you here because what they imply is some-kinda fixed set of features what are delivered to certain date.

>You're choosing to conflate listening to customer feedback with Agile

HE draws that link... >In this post, I’ll present a robust and disruptive Agile framework. It’s called “talk to your customers” — or, in short, TTYC.

Reply on news.ycombinator.com