"So the rocket launch is planned for October, will the software be ready?"
"Not sure, the software developer team doesn't like deadlines, they'll be finished when they feel like it."
"Not sure, the software developer team doesn't like deadlines, they'll be finished when they feel like it."
When people are producers they don't like deadlines but as soon as they are consumers they demand them.
Go build a house and you'll be constantly asking "when will it be done" and "whenever" isn't acceptable to you.
Order something from Amazon and "it'll arrive whenever it arrives" isn't acceptable to you.
Sell some stocks and ask your broker when you'll get the cash and "whenever, in a few days, not sure man, asking me about dates really takes me out of my Flow State" doesn't sound so great.
We want deadlines. We want to know when our iPhone will be repaired, when our drycleaning will be done, when our children's schooling will be done for the day, when our plane will take off, when our car repair will be done, when the movie will start, and so on.
I always find that these kinds of articles can too often come across as "deadlines for you, but not for me" if they don't really grapple with that reality and try to come up with explanations for the dichotomy.
Building a house is the same, yet we want our builder to tell us deadlines and get upset when he misses them.
All infrastructure work is the same, yet we gleefully complain about how that subway/overpass/bridge/new airport is behind schedule.
Medicine is the same, but we become (extremely!) upset when our doctor is 60 minutes late to our appointment and we have to wait.
Teaching is the same, but we'd flip out if our teacher decided to keep kids an extra 20 minutes and we're waiting outside in our car to pick them up.
Heck, just look at how upset people get about how long it takes George R.R. Martin or Patrick Rothfuss to write their next books!
I guarantee many of the same people complaining about George R.R. Martin taking so long also complain about their boss asking for estimates and setting deadlines.
And on and on and on.
Custom/self builds are famously hard to predict, and nearly always go massively over budget and over time (twice as long, twice as much is more common than on budget, on schedule). Often because there are significant changes to the requirements as the project goes on, because the customer changes their mind, or because unexpected things are discovered during the build.
In fact, with the arguable exception of teaching, which is a classic example of deliver to deadline with no specific set of features, all of your examples are things that people are unable to accurately predict.
They might be correct for overpass #10,000, build #300 of Standard House Model B, or churning out antibiotic prescriptions. But those projects should cease to require much if any engineering support, leaving only the ones with more unknowns.
Subway tunneling is a really great example. You run into underground infrastructure that wasn’t in the documentation and you have to stop and figure out whether it’s still used, what it’s connected to, etc. and either refactor it out of your way or change your own route before continuing. You don’t know in advance how many such situations you’ll run into or how difficult they’ll be to untangle. So subway projects are chronically late and over budget.
So why the hate for deadlines? Software engineering does not exist in vacuum separated from business constraints like runway or annual budgets. To demand deadlines of your employer but to not be willing to even try to meet deadlines in deliverables seems to me to be a bit unprofessional and disconnected from the underlying business reality. A whole company that wants to shrug off this underlying business reality seems even worse. A series B startup that doesn't meet deadlines might not even be in business in 6 months.
"Yes, it will. But we can't guarantee it will work correctly."
Choose your poison.
If you're competitor is imminently releasing a competing product then what you're working on isn't really novel. It would also be potentially patentable if it really was novel, which would grant you a monopoly on the space.
> As well as this, the time between having a product or feature complete and ready for release equates to lost revenue.
What's the lost revenue from releasing a buggy product? What's the lost revenue if your competitors are about to release a working one? What's the lost revenue from your developers jumping ship and all the related turn over costs? Some of those mistakes could sink the product/business entirely.
> to maximise possible revenue.
You agree that maximizing revenue at the expense of everything else isn't the goal don't you? If that's all that mattered then development would be outsourced to a third world country to save on expenses. But we've mostly learned no to do that because despite promising revenue gains they lead to several bad outcomes in the short and long term, pushing hard deadlines is no different.
Most of us aren't writing code that will go to space, but most of us work with other parts of the business, and marketing, management, investors need agreed deadlines to coordinate with.
But that bootloader had better be flawless!