Comment by freddie_mercury | Hacker News Reader

Comment by freddie_mercury | Hacker News Reader

Parent Full thread

freddie_mercury

I'd make a related argument:

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.

In addition to this, to narrow the scope strictly within software engineering, I don't think too many people on HN would sign an employment contract that states that cash will be paid or equity vested "whenever".

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.

If you understand a software task well enough to profile, optimize, and make correct predictions about it (the way UPS does with package delivery, or Lennar with exurb manufacturing), you understand it well enough to build a reusable solution. If you have good architecture and code reuse, the share of time that a team spends on well-understood tasks with accurate estimates should approach zero. Software scales - that's the point.

This response strikes me as a typical "software development is so special we have to live by different rules" response that developers all too frequently make. Software development is not as special we often make it out to be.

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.

Building houses is an excellent example. When a large corporation is building an estate, the time and cost taken to build the houses is fairly well known, and consistently accurate (to a degree).

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.

People can want estimates and deadlines, but the estimates won’t be correct and the deadlines won’t be met for an ambitious custom build house, a subway tunnel through unknown “legacy,” or a diagnosis and treatment of an exotic disease, because that’s not how it works.

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.

Reply on news.ycombinator.com