
Driving engineers to an arbitrary date is a value destroying mistake - signa11
https://iism.org/article/driving-engineers-to-an-arbitrary-date-is-a-value-destroying-mistake-49
======
7532yahoogmail
Software dev 20+ years: management is right to ask for estimates. It's ok for
engineers to write a throwaway design paper to "get into" the problem before
turning to jira epics and stories. It's also right for engineers to reject
arbitrary dates, pressure to cut corners and so on. But this or the ops story
absolutely don't get anybody anywhere.

You wanna move beyond anecdotes and nice sounding business arguments? Read
FIRO by Dr. Schutz prob out of print or "Human element" by same. His son Ethan
has updated these books.

Look, in normal high functioning groups conflict is normal. What confers
distinction there is two things:

\- no individual on team is ridgid and unchanging

\- conflict is resolved with 100pct buy-in ie not cause the boss yelled, or
you were out gamed, politics, favourites. IOW there is trust in the team
(together with self awareness, competence etc which the book hits on)

When human factors burn down projects down the issues are quite a bit more
about trust, individual self awareness, defensive behaviors, and not resolving
the problem in a group way. Trying to eliminate conflict with rules of thumbs
is a fool's errand. Conflict itself is not a sign of badness.

References to organizational modalities (the strong boss, the clear vision,
and similar sounding approaches) help at the margins only and then only
randomly.

~~~
gilbetron
> management is right to ask for estimates

Why? They are always wrong. Asking for a plan? Sure, because planning makes
you think through things. Planning good, plans bad, to paraphrase. But
estimates are always wrong and always useless, dev with 30+ years experience
and I've never met anyone that can actually estimate software except in the
trivial sense.

The error bar on software estimates, like solving a math problem (because they
are the same thing! If you don't think so, you don't understand software), is
infinite.

Although I like your quote that "conflict itself is not a sign of badness".

~~~
outericky
Why? Because there are often other dependencies going on. Most software in
this paradigm is at a company. When companies roll out new things, change
management has to happen. Marketing needs to make a splash (they want at least
6-12 weeks lead time). Sales starts making promises. Account managers and
support need to be trained. Change management has to to happen. So then
missing a date by weeks/months screws up the business. Most companies aren't
writing software for fun.

------
john_moscow
As a person who runs a small software business, coding most of the
functionality myself, I actually disagree with the article. There is a huge
value in setting deadlines because they force you to prioritize things. Once
you realize that you don't have the time to ship features X, Y and Z, you
start comparing their impact/complexity/risks, pick the most beneficial one,
and ship it before it's too late.

Without prioritization it's very easy to get stuck in a loop of endlessly
adding small improvements/testing new ideas, but never releasing the final
sellable product. There are a few notorious examples from the game industry
where no time pressure lead to either no product, or a hopelessly late-to-
market product (e.g. Half-Life 3, Duke Nukem Forever). There are more smaller
examples where entire teams endlessly juggle the code between web frameworks,
as they come in and out of fashion, and neglect more user-impacting features.

That said, most of time pressure should only be applied at the decision-making
level. Once you have decided to ship feature X with framework Y, it's useless
to nag on your devs to do it in half the time by dropping unit tests, or doing
60-hour work weeks. Instead, you should have picked feature Z with 50% the
complexity and 80% user impact.

~~~
tikhonj
Prioritization is the key thing.

I have a simple rule of thumb: a deadline is a "real deadline" _if I would
reduce scope to hit the deadline_.

A deadline is just a goal if I would _not_ be able (or willing) to reduce
scope to hit it.

Treating a date as an absolute deadline _without being able to adjust scope_
is where productive work gets totally derailed.

~~~
mmcnl
Great insight. A deadline where the only thing you can change is the hours you
put in, is not a deadline, it's exploitation.

~~~
troebr
There are multiple ways to make a project fit into a deadline: \-
change/reduce the scope => lowers the value of the product \- cut corners: for
ex. skip testing, ignore bugs, work faster, skip code reviews, etc. => lower
quality \- work longer hours (lower quality + human cost) \- throw more
resources at the problem: may scale poorly if at all, as well as usually
results in lower quality and more friction, aka human cost

It's all about weighing everything and making the right trade-offs. Sometimes
short term solutions are the right approach, maybe you need a POC more than a
polished product to get that next round of funding or something.

I've struggled with that in the past, and next time I'm presented with this
kind of project, I'll clearly explain the trade-offs, for example translating
lower quality to: this may increase the number of bug reports significantly,
increase the maintenance cost, prevent the addition of other features with
significant overhauls, this and this engineer may start looking for another
job, etc.

------
kabdib
Confession time: In 40+ years of doing software, I've met my schedule once.
Actually, that's a lie. I missed by a week on a 150-day long project, my very
first project at my very first real company, and that's the closest I ever got
with my own estimates. And on that project, marketing wanted it pulled into 30
days (and to hit that 150 days I was doing all-nighters and basically killing
myself, so it wasn't a very good schedule to begin with). [For the curious, it
was a game cartridge].

The real losers of "schedule chicken" are the customers, who receive buggy and
bad products. The company will suffer long product update cycles because of
the effort needed to stay ahead of the quality debt. Explaining this to a
manager who's never even read even one of his copies of _The Mythical Man-
Month_ can be tough.

Things aren't necessarily better when you let a project freewheel. "You'll
ship someday, just do a good job and get it right" doesn't necessarily
translate into the urgency to ship a product, and I've seen efforts on the
scale of tens of millions of dollars fail.

Other arbitrary dates include things like shows (well, what is the real cost
of missing that show versus shipping something buggy to bad reviews?) or
holidays (hitting Christmas used to be a good excuse for schedule pressure in
the game industry, much less of an excuse now).

[Anecdata: Years ago there was a manager at Microsoft who told his team to
ship by some arbitrary date, which turned out to be when he was planning to go
on a long vacation. I'm happy to say that Microsoft fired him.]

~~~
commandlinefan
> I was doing all-nighters and basically killing myself

I often suspect that the true goal of most time-estimation exercises is to
guilt you into working unsustainable amounts of unpaid overtime.

~~~
Insanity
Why would you though?

I don't see the point in working all-nighters for a company unless you have a
stake in the company (shares or owner). For my own company, sure I'll pull an
all-nighter before an important meeting, for a company where I am one of
hundreds? No thanks.

Labour laws tend to be more protective here in the EU though so no fear of
being fired by refusing rediculous requests.

~~~
latencyloser
If you don't do it, there's always a willing colleague who will. At least,
that's been my experience in FAANG and related companies. Since I
became...complacent, I guess... and started only working 9-5 for the most
part, I can't keep up with my colleagues who are working seemingly every
waking minute. It's a great way to get passed up on promotions, not get handed
the "good" projects, and just generally be sidelined from decision making.
Ymmv of course.

~~~
throwaway713
> If you don't do it, there's always a willing colleague who will

Haha, isn't this the truth. I work at one of FAANG as well and was curious how
one of my colleagues was accomplishing _so much_. His output is astonishing. I
checked his work profile and noticed he had commits, notes, and research
actions starting at 7:00 AM and going until 1:00 AM the next day, every day,
including weekends. I don't think the founder of this company ever even worked
that much. I guess there's just some people who never burn out. Meanwhile, my
wife gets annoyed about dinner when I work past 6 PM...

~~~
purerandomness
Give him 6-9 months. He'll disappear, all of a sudden.

We all do this. Once. When we grow up, at ~23.

~~~
kabdib
Once, at 21 (an Atari game). Again, at 31 (the Apple Newton). And again, at 41
(the Kinect).

Every ten years or so I get stupid, I guess.

I guess I finally wised-up when I turned 51, we'll see if I stay that smart in
a couple of years :-)

~~~
purerandomness
I guess the key here is that you can totally immerse yourself in something
that doesn't feel like work; a project that fullfills you from the deepest of
your heart.

That tends to happen once every 10 years.

It doesn't tend to happen in day-to-day grunt work at an AdTech shop, pushing
JIRA tickets.

------
dasil003
This post highlights the importance of competent technical management. The
problem is not arbitrary dates, it's unreasonable dates with inappropriate
feedback loops and lack of trust throughout the management chain. The example
given is a strawman of a classic cigar-chomping executive whose philosophy
comes largely from unskilled, fungible-labor economies.

Taking away the date is definitely not the right move. Now you've given every
PM and sales guy carte blanche to throw whatever flavor-of-the-moment idea
comes in their head. The team will be churning constantly to keep up with the
requirements and then someone will suggest, "I know, let's do scrum!" so now
we can all enjoy the stress of unreasonable deadlines on a continuous rather
than waterfall basis.

To the contrary: a properly-managed date is an incredibly valuable constraint
which the entire team can use to make tradeoffs against. To make it work
management needs to trust the team, and engineers need to understand the
larger business picture because they are the ones with the knowledge to find
creative solutions that _actually work_ and decrease time to value without
compromising technical quality or long-term maintainability.

~~~
jerf
"In preparing for battle I have always found that plans are useless, but
planning is indispensable." \- Dwight D. Eisenhower

Took me some years to fully internalize this, but I endorse it.

~~~
war1025
Related, when I was in school, I always took meticulous notes during class.
But I never looked back at them.

I.e. Notes are useless, but note-taking is invaluable.

~~~
renewiltord
How funny, I took notes for a class to A/B test this and note taking ruined my
ability to internalize data. When I wasn't taking notes, concepts would fly
into my head as I'm writing an exam along with the associated memory (where I
was sitting that day, whether it was bright out, where the lecturer was
standing wrt board). When I took notes, I had all these notes and none of this
would happen.

I used pen/paper. I also tried, separately, computer-based stuff and that
ruined my ability to concentrate.

~~~
war1025
For me the note taking helped with the internalization process of linking the
information with the memories of the professor talking about the lesson.

I think the key is to still allow your mind to wander and build the
connections. I found I always had the best luck if I was a little distracted,
but mostly paying attention.

Perhaps because the variations in attention helped to differentiate which
information felt important vs what was just background noise.

~~~
renewiltord
Interesting. Ah well, the time has passed on that front.

------
ineedasername
I dislike articles like this. They take a situation that isn't representative
of the workplace everywhere, generalize it, and come up with a universal
"never do X!" headline that grabs attention.

There's nothing wrong with deadlines, even arbitrary deadlines. Without them
it's easy to get lost down a side path of "oh, it would be nice if we could do
X". They serve to focus attention. The thing is not deadlines, but how you
work within them. If it's arbitrary, Work backwards from the deadline to what
can reasonably done, and present a detailed account of those estimates. If you
have a hard-charging "just get it done" boss, part of your responsibilities is
to manage upwards, educating your leadership on what your job entails so they
can have reasonable expectations. _Most_ managers are not actually pointy-
haired bosses, but you have to work towards that relationship: if you treat
them like a PHB, you'll give them no way to evaluate your work except their
own faulty metrics.

Will this work in every situation? No. But that isn't representative of some
universal problem with deadlines, it's representative of poor management.

here's nothing wrong with setting dates. There's nothing wrong with setting
arbitrary dates

~~~
MaulingMonkey
Even impossible deadlines aren't the end of the world. "We need X Y and Z done
in N weeks!" "...I'm not sure if we can get even one of those completed in N
weeks - and that's even before accounting for the fact that I'm an optimist
among optimists. Since it's so obviously impossible, I'm not going to kill
myself trying - instead, let's talk prioritization, so we can deliver as much
value as reasonably possible within the deadline, if it's really an important
one."

What you want to avoid:

1) Pressuring devs into crunch/burnout/quitting/morale loss/checking out.
Turnover will eventually cause brain drain when your best talent leaves for
greener pastures, and makes hiring more expensive when your reputation sours.

2) Pressuring devs into sacrificing long term productivity for meaningless
short term milestones. It's one thing to prioritize a feature or two for an
important presentation to investors who will be making decisions about your
financial future at the temporary expense of, say, test coverage. It's another
to do so routinely that codebase stability suffers, developer velocity gets
wasted on disturbingly routine debugging sessions, and build engineers disable
code coverage metrics for being "just too gosh darn depressing to even look
at."

------
wwarner
I think the article lacks nuance. Of course, asking devs to guess at how long
something will take at the very beginning of a project is not going to be very
accurate. That doesn't mean that sticking to a schedule has no value.

Basically, the project plan has to allow for some scope cutting along the way.
There will always be a few false assumptions that are discovered only after
the project is well underway, and the only way to manage that is minimize the
surface area of any given dependency.

The responsibility of delivering a project on time belongs to the manager
(which for the purposes of this comment can belong to an IC if she or he
decides to think like a manager). For every milestone on the schedule, the
manager should know all the risks for reaching the milestone and should have a
plan for handling each eventuality.

This type of planning goes hand in hand with protecting the team from
distractions, preventing scope creep at all costs, and setting the goals of
the project before it has even started.

Software created with time constraints is higher quality and is more fun to
make.

------
typl
Bob Martin's new book "Clean Agile" covers this topic well. The problem isn't
dates or deadlines, it's arbitrary dates or deadlines that are not backed up
by data that indicates whether or not they are achievable. Often we create
estimates with no prior knowledge of the team composition and particularly
their ability to apply their skills to the problem at hand. The only way to
make good estimates is to give them work, let them start doing it, and observe
their progress. You then can manipulate the scope of your project to determine
what you want done (the highest value things) and estimate when you can get
those things. The alternative levers (add a bunch of people, sacrifice
quality) end up not working in software projects and become the "value
destroying mistakes."

------
bane
"Real artists ship" \- Steve Jobs

After about 20 years working in tech, at multiple companies of all sizes, and
in dozens of teams, working through all levels of engineering, management, and
other jobs, I can say without _any_ hesitation that without due dates
(reasonably negotiated of course), engineers will spin indefinitely and
nothing will ever ship.

~~~
atoav
Depends. I am a MA who fittingly studied art. The university I studied on is
one of the few without nearly any time pressure. You can take as long as you
like.

A receipe for disaster? Only produces bullshit results? Far from it. Ofc there
is a percentage of people who just cannot deal with the freedom, but in terms
of results (I studied in the Film department) this school creates the best
films with the lowest budgets in the country. Most people that work from you
get nothing for the job.

Again fittingly I now work in the IT department of said university, where I
often create software that we need. There is never a deadline, only a
"Somebody needs this and wants to use it and is doing a horrible manual
workaround in the meantime" that is usually a far better motivator than an
arbitray deadline.

Rhink about it this way: Imagine you are a carpenter and you have to build a
cabin in the woods. What motivates you more:

a) An abstract deadline set up by your manager (you know the cabin will be
sold to some rich guy who doesn't need it anyways)

b) Someone you know will live there. They are couch-surfing with their family
in the meantime. There is no deadline.

Both create pressure, but one is by far a more effective motivator to do
things fast yet good than the other.

Of course that would mean your company has to solve meaningful problems with a
natural deadline.

Natural deadlines by their nature are usually fuzzy. The trick is: make your
engineers care. If you can't, you either hired the wrong person with the right
skillset or what your company does is not important enough to most people.

Many programmers and engineers instinctively _know_ that their work acts as a
multiplier for good or for evil. However if you multiply anything times zero
it remains zero..

------
brightball
This hits on exactly why I was drawn to SAFe.

After all the feedback I got from this...

[https://news.ycombinator.com/item?id=17154355](https://news.ycombinator.com/item?id=17154355)

Someone pointed me to Reinertsen's Principles of Product Development Flow
book, which put into numbers and models everything I'd been trying to say (and
then some).

It worked great with my team, but I was failing hard at communicating and
involving everyone on the business side so I started researching for something
that provided the business side, wrapped around his methods. Which drew me to
Scaled Agile Framework.

There's a lot in it, but the core of it is simply on a pace of 8-12 week
increments, you spend 2 days letting your developers provide you with a plan,
estimated based on 2/3 of their actual available time. They make the
plan...not management.

The plan is presented to management, management discusses tradeoffs and
options, then ultimately management will accept a final plan and the
developers provide a confidence level in their ability to deliver the plan
that they have set out.

When new requests come in, they are discussed for the next 8-12 week increment
so the developers can focus on executing the plan that everyone agreed on.

There's still room left for small things that come up, there are progress
check-ins and communications that happen along the way. Risks to the plan are
identified and discussed so everyone is aware of them up front. Variability is
assumed (up and down) throughout the plan. The only assumed commitment is to
the 8-12 week deliverable. Nothing in between is expected to have a guaranteed
delivery date.

It leaves little room for surprises and plenty of room for people to work in a
reasonable manner. I can't speak highly enough of how effective it is to
addressing this problem.

~~~
andi999
You should multiply the plan of the developers by 3-4 before presenting to
management. So management can cut to factor of 2-3 and you will barely reach
it. I never met a developer who doesnt underestimate the effort needed by a
vast amount. (including myself)

~~~
brightball
Management doesn’t get to cut the plan. They get to ask “what if we don’t do
this, would it be possible to get this instead?”

There’s no “we said it will take X” and management saying “do it in X/3”.
That’s no longer a plan made by developers that developers are comfortable
standing behind.

Over 10 weeks, you would plan based on 2/3 of time for 8 weeks, with nothing
planned in the final 2. If things are running behind, this becomes buffer to
finish it out. If things are finished on schedule by the 8 week mark then the
final 2 weeks becomes time for developers to pursue other things. Training,
prototyping things they’ve wanted to build, whatever.

It’s the old Google 20% time concept built into each increment.

------
fsloth
You need some estimates if you need to sync the efforts of two or more teams.
For single teams with single deliverable there might be a necessity to set a
date, or might not.

But if there is no _external reason_ to push for a date then setting an
arbitrary internal date when it provides no additional value is just silly.

~~~
convolvatron
been thinking about this because my current project has suffered from
management repeatedly setting unreasonable dates. which causes flailing to get
stuff put in, and then we the date finally gets moved out, more stuff to paper
over that crappy stuff.

but you have to admit that without a date developers will just noodle around
forever.

I think the only recourse is to constantly be evaluating the current slate and
the date and keep sliding it out as necessary or throw stuff off the train.

really, you should never miss a date. you should have realized some time ago
that it wasn't going to happen and slid it out already.

~~~
Twisol
> you have to admit that without a date developers will just noodle around
> forever.

This seems more a statement about extrinsic motivation than dates in
particular. Dates are the most obvious blunt instrument for applying extrinsic
motivation, but there are others.

Intrinsic motivation is in some ways even better. You can't force someone to
be intrinsically motivated to achieve something... but pushy dates and
expectations can decimate any motivation that was already there.

------
nimbius
disclaimer: I am not in STEM, im an automotive tech who is learning python.

Why do software developers have arbitrary dates at all? We certainly dont. If
a customer says they want their work done by the end of the day, we'll take
that into account, but the best we can do is estimate how many hours it will
take to work on, update you on our progress and inform you of obstacles we
encounter. Work proceeds at a _safe_ and _productive_ rate.

~~~
johnvanommen
A big chunk of it is probably writer's block.

For instance, if my wife asked me to make a pizza, I know very specifically
what steps are necessary.

When a client asks my employer to create a piece of software, it's a lot like
being told to write a book. Sometimes you don't know where to begin and a lot
of the time you get the thing 40% finished and you feel like throwing it in
the trash and starting over from step one.

------
petedoyle
> "We believe that communicating dates produces the wrong incentives. What
> really matters on a long timescale is 1) priorities and 2) velocity." [1]

I saw this written during the 2017 cryptocurrency craze. Has stuck with me as
one of the most insightful things I've ever read. Also a fan of 37 Signals'
budgets. [2]

[1] [https://medium.com/graphprotocol/introducing-the-
graph-4a281...](https://medium.com/graphprotocol/introducing-the-
graph-4a281b28203e)

[2] [https://signalvnoise.com/posts/3746-drive-development-
with-b...](https://signalvnoise.com/posts/3746-drive-development-with-budgets-
not-estimates)

------
TrackerFF
One persistent problem I've encountered, is that this kind of nonsense very
often translates into the bidding process of large projects.

If you come up with a realistic offer, which should be pretty close to reality
in both time and budget, you're out of the race. Other contractors have put in
offers with totally unrealistic numbers, making you look both slow AND
expensive.

And like clockwork, the undercutting (bid) winners will deliver a 60% finished
product come project due date, and then spend years on fixing bugs and
"upgrades".

Their in-house devs, and outside consultants for that mater, are worked to the
bone. Bugs happen, and the tickets pile up.

And worst of all, these companies get awarded new projects, again and again.

------
commandlinefan
Lazy thinkers like to measure dates because they're easy to measure. I don't
think I've ever, in my professional career, seen a date get "hit" \- by me or
by anybody else - and I've also never seen it matter.

~~~
recursive
> I've also never seen it matter.

It matters plenty of times. If Turbo Tax doesn't ship their 20xx edition by
Jan 1 20xx, they're losing sales. I also work on (non-tax-related) software
that is tied to specific dates by regulations coming into effect on certain
dates. I don't think this is rare.

------
Tomte
I used to work for a company where important deadlines and release dates were
often cast in concrete. At the birth date of the former CEO (husband of the
current CEO) who had tragically died many years before.

So if your "natural" release date was a few weeks after that birthday, it was
definitely on that birthday. You only had a chance to escape that if your
"natural" release date was months apart from the birthday.

But then again, this company never ever hired anyone without a positive
graphological expert's report.

------
gfxgirl
In games, at least in the past and I'm pretty positive still, you have to make
commitments months in advance. Want the cover of some magazine? It's decided 6
months in advance. Want TV commercials to run? Book them 6 months in advance.
Want your ads on billboards or large displays? Again, several months in
advance. Want shelf space at Walmart, more of the same.

So, your company, generally, has to book all of that stuff long before the
game is complete. So they go to the team and ask. When will this be done? The
team says (in 24 months) and so marketing and sales get to work making all the
deals for the things above and now the team has to met their deadline or all
that stuff above is not only wasted, those people will never work with you
again because you messed up their scheduling. This is especially true for
retail space because it's not like they can fill the shelves with random stuff
on a moments notice. THey've basically got a hole in their inventory and shelf
space they would have filled with another product so you've made them lose
money.

Much of this is also true for consumer electronics. Deals are made to feature
the next smartphone at all outlets, and run commercials etc, months before the
phone is ready to ship. All the teams making software for that device have to
be ready to ship by that promised date.

~~~
dhbradshaw
FYI, the billboard lag time was true until a few years ago, even for digital
boards.

But now you can turn on a national campaign in a few days. (Disclosure: I work
with Blip Billboards who are one of the major drivers of this change.)

~~~
gfxgirl
How do you do that if they are all booked? Do you just price to the highest
bidder so if I wanted my new Star Wars movie on the billboard on May 4th and
you want your new Star Trek movie on the same day who ever pays more gets it
even if one booked it months in advance?

~~~
dhbradshaw
Right -- there isn't any booking its just about who brings the money for that
sign on that day. You can pre-declare how much money you want to assign to an
hour and sign but can't know that you'll win for that sign and hour. If you
don't win there, you keep your money to use elsewhere.

But we have ~1500 signs and each of them is playing a new ad every ~8 seconds.
In other words, there's plenty of space. Those 8 seconds can range from a
penny to a buck depending on the time and place and on the current
competition. If you want to show up, you can.

------
at_a_remove
Estimates are never good enough, when asked you're supposed to tell them two
weeks _before_ their guess. I recollect one project with a hard deadline. This
landed in my lap during a worthless business trip while I had a fairly serious
cold. I had about five weeks, all on my lonesome. It was _critical_. I had no
time and no energy but tackle it I did.

I had precisely one meeting with the person who issued the project, during
which he made various Agile noises. This taught me something I would later
come to expect about those sounds: I met with the stakeholders precisely
_zero_ times before delivery, despite my repeated asks. I worked evenings and
I worked weekends to deliver something on time that was perhaps a little
better than expected.

And crickets. For five long months, nothing. I asked tentatively and was told
I got paid whether or not it was in use.

So this strangled two values for me: Deadlines, certainly. If I hear a
deadline, I evaluate from where it came. If it is a nonsense deadline, I lose
respect. False urgency is just a way of life with some people. Additionally,
the "getting paid whether or not something was used" is an excellent way to
develop apathy in an employee, it destroys the value of engagement.

Sometimes real dates exist, and I'm all for that. Floods can be expected. But
too often dates are picked out of a hat.

------
wwarner
Contrast with Patrick Collison's essay on the value of speed.

[https://patrickcollison.com/fast](https://patrickcollison.com/fast)

~~~
temac
This is not an essay, this is a bunch of anecdotes.

So projects that worked reasonably well and developed very fast, or even just
somehow fast, are presented. Everybody agrees that's good and a success and
better than if they were done slower; but so what?

Some are great major engineering projects, but in the context of extreme speed
there is a world between a few weeks or even months, and more than 5 years,
even if you compare the 5 years in question to project that are a parody in
the other direction (yeah, a train project that is planned for 37 years looks
ridiculous, but again so what? is it really because diva engineers want to
spend all their careers doing "perfect" stuff and reject any deadline they are
presented? doubtful)

Also, some are successful, but controversial (JS...); some I don't even know
what to think about (is growing the population of a city by 22% in a year
good?); some are just the work of geniuses.

And this is a mix of major physical infrastructure/engineering projects,
projects for mass produced physical goods, and random software projects. Then
suddenly the discussion focuses on physical infrastructure, ignoring all the
other kind without even stating why.

This is also hard to contrast with the original article, because we don't know
how many of them were mainly date driven. Probably not so much, in the sense
that it would be retarded to insist on delivering something that cost a
shitload of money to build at a completely arbitrary date without enough
concern about the quality.

Too finish: some insane major infrastructure projects have been successful in
the modern age: what comes to mind is for example the LHC, yes it took quite
some time but it is probably somewhat more difficult to design than a random
consumer electronic gadget? (is the story of the iPod that much spectacular? I
found it quite common...)

------
sys_64738
It's a developer's job to meet their deadlines. If they can't make them then
they should be negotiating with management. It's all about risk management.
Every developer needs to own their deliverables. No dates means no deadlines,
lack of focus, lack of closure, lack of product, lack of revenue, lack of
money, lack of job.

~~~
rossjudson
High functioning teams with sustained value creation don't need deadlines.
They're not working on one thing; they're working on many things. There's
nothing to "adjust" by imposing a deadline. You can reprioritize, but the date
is just noise.

~~~
agotterer
This. I couldn't agree more. My current team is high functioning and regularly
delivering value to the business. Delivering value is our measure of progress
and success.

Sure, we set goals which have dates attached. We usually plan out a whole
quarter of what we want to accomplish. Our timeline is based on best guess
estimates. We aim to deliver 80% of what we committed to. Sometimes we do it,
sometimes we don't. The business rarely complains because they see regular
value being delivered. When things aren't going well we communicate openly and
regularly so that no one is caught by surprise.

------
hvs
What ever this is, the use of colors, arrows, bad clip-art, and everything
else just yells, "DON'T LISTEN TO ME."

~~~
throwaway3563
The slide at the bottom has “non-technical executive hocus-pocus” written all
over it but I thought the rest of the content was sound.

------
thsealienbstrds
I don't believe that not setting a deadline is the solution. There are
definitely software engineers who will happily change their designs an
infinite amount of times if you let them.

> The testers keep running into situations where things don't seem to be
> right, luckily your product manager is happy to defer most issues raised
> unless it is a real "show stopper," as Jeff loves to exclaim.

That might have been the critical mistake. Jeff should not have done that. He
should have insisted on lots of feedback loops during the project. He should
have put more effort into convincing himself that the product is of sufficient
quality.

As for the developers, they should have made it clear to Jeff: if he's not
allocating resources to convince himself that the product is of sufficient
quality, he shouldn't be mad at them when in the end the product doesn't work.

------
madeofpalk
> While it is true that a narrow set of low value software projects are
> tamable with a Gantt chart, high value software projects that fill
> previously unmet needs do not lend themselves to being tamable by predictive
> scheduling techniques.

I think the author vastly overestimates the value and importance of project
that most developers work on. I don’t think I’ve ever worked on anything that
I could consider “high value”. I’ve worked in big (and small) companies,
working on Big Important Projects, but if I’m being realistic I think the
overall value and actual importance is actually quite low.

Other than that, I think the essay has a fatal misunderstanding - it’s not
about setting deadlines, but it’s about estimating what it costs to do build
software. This is useful because it helps us guess when it would be done, how
much can be delivered, etc.

------
geekraver
I am old enough to have been writing software since 1976, and still do,
although I am mostly a manager of managers now. My view is that dates are
unfortunate (but sometimes unavoidable in the real world). But estimates are
useful. They help flesh out risk, uncertainty, and ambiguity. They provide a
set of approximations against which you can plot a glide path. And of course
they must be frequently updated in the face of a changing reality. But that
constantly evolving glide path is the “current best known” ship date, and that
is very useful information (actually you can go deeper and look at its rate of
change to give a better approximation).

It’s the job of engineering management to convey to upper management that
these dates are projections only with certain levels of confidence.

------
flattone
I wish somehow engineers could stop being told what to do. They should be
saying what should happen.. right?

~~~
ipnon
This is the case when "Jeff" and the "Big Boss" can do the job they are
managing. Examples include Zuckerberg at Facebook, Collison at Stripe, Musk at
SpaceX.

Every new hire at Toyota has to work on the assembly line for 2 weeks before
they can begin their role. This applies from secretaries to vice presidents.
How many software companies can say the same thing?

No one who manages my job is capable of basic web development tasks, e.g.
centering a paragraph. The result is they are continuously confused and
frustrated and our group is unproductive.

------
goto11
I know it is not the point, but I find it funny that the "Code done with care"
is worse than the "Code done under high pressure". Logging and wrapping is not
"handling" an error, that is just making the exception go away.

------
xupybd
I had this happen. First time I'd used a framework for more than a few
screens. Totally new way of doing things. Learning RXJS, made a mistake in
understanding one of the more strange requirements. Time blew out. But the
delivery date was 3 months. Worked crazy hours, product didn't ship the entire
thing was seen as a failure.

I was burnt out for a good 6 months after that. Even simple tasks took all of
my will power to do. It was horrible. 3 months of the hardest work I've done
and considered a failure for it.

------
huffmsa
It doesn't destroy value, it means your team over-scoped the deliverable value
at the outset. Shipping dates are good when used correctly.

1\. We have this high level idea, we want to ship it by XXXX

2\. Here are the features we want it to have that we think can get done by
XXXX

3\. Here are the features prioritized from mandatory to nice-to-have

4\. Move the bottom 10% of features to v2.5

5\. Move the next 10%-20% of features to v2.0 to make room for bug fixes, acts
of god and management led boondoggles

6\. Start development.

------
cjohnson318
Like, sure, if you want me to write Hello World, then I can give you a snappy
timeline for that. If you want a POC of something very few people have ever
implemented before, then that's going to take about a week. If you want that
POC to be ready for production, then that's going to take a lot longer than
you're comfortable with to test and develop.

------
scruffups
The title is a great test for conversational AI. I thought this was about
driving (in a car) engineers to an arbitrary (blind) date.

------
JulianMorrison
It's also about 98% of "agile" \- I don't mean the big deadlines, but the
endless meaningless little ones. Why are N days okay to finish a thing, N+1
days not okay, and you have to endlessly salami slice it contrary to common
sense until you fit in N?

------
shkkmo
The solution in this hypothetical is that the technical manager should have
pushed back on efforts to squash estimates, and instead gotten the feature set
reduced down to what would fit inside the desired launch window.

~~~
commandlinefan
I've seen that tried, I've never seen it actually work. What I've always seen
happen is, they'll ask if _X_ can be worked into the schedule, the devs will
say no, it can't. Then the next day, they'll ask if _X_ can be worked into the
schedule (usually phrased just a _little_ bit differently than before), and
the devs will say no, it can't. Then a week later, they'll ask if _X_ can be
worked into the schedule. Then, when the devs say no, it can't, they accuse
the devs of pushing back on everything, so the devs finally roll their eyes
and agree to _X_ (knowing that it's impossible to deliver because it's not
even defined, but who cares because nothing ever happens when you inevitably
miss the dates anyway). Then the next day, they ask if _Y_ can be worked into
the schedule...

~~~
MaulingMonkey
"No" can be interpreted as pure obstinence.

"We can do X... I suspect we'll need at least N weeks after we have a proper
scope/spec/X/Y/Z from you, though, so if you want it done by $(MILESTONE) we
need it by $(MILESTONE-N) at the absolute latest, or more preferrably by
$(PREVIOUS_PLANNING_MEETING) so we have some wiggle room. No, that's not a
spec. Yes, you need to participate in defining the scope of this thing -
otherwise it'll take even longer when we're forced to rework completed things
to work how you actually wanted them, and longer still when we work on things
we thought you'd find important but don't care about. When can you meet so we
can get this properly defined and fleshed out? We need a meeting anyways to
discuss what other things you want that we're going to have to cut or defer to
fit this into the schedule as well."

If they work with you to cut/defer other things they've asked for and actually
get you a scope/spec/X/Y/Z on-time, then good! You've successfully responded
to a change in their priorities.

If they suddenly lose interest when _they_ might have to do some work...
you've probably deflected some high work low value ask. Also good!

If they put in the work but can't get you scope/spec/X/Y/Z in time... well,
hey, that's not on you. You need enough time to get these things done.

They might still want 3 women to make a baby in 1 month... but they might
believe you when you say that's not possible if you at least _look_ like
you're trying to work with them on fitting X into the schedule.

------
seph-reed
Total aesthetic digression: Having the topbar offset inversely based off ~1.5x
the scroll position is one of the coolest effects I've seen for hiding top
bars.

I like this a lot more than the sticky style that most things use.

------
jimbob45
My current thinking is that sometimes deadlines are needed and Scrum can make
that happen. However, the deadline you get from the engineers is going to be
vastly slower than if you'd let them just do the work and tell you when it was
finished.

I know marketing lines to pretend that they can't do their jobs without hard
engineering deadlines but marketing is overrated anyway. Ask yourself if you
really need a deadline or if you're just slowing down engineering with your
incompetent management.

------
uberdru
The lost art of 'scoping'.

------
lihaoyi
e

------
freepor
If you are paying people on a schedule you need to have at least a rough
understanding of what they can produce on a schedule. The best illustration of
this is client work that is paid "by the job" \-- you need to understand what
you can produce to have any idea how to bid.

------
mmcnl
It annoys me so much that many people think software development is
misunderstood. You think people in other types of business don't have to give
estimates based on almost nothing? This happens everywhere, anywhere. But
somehow software engineers think they are special and are being treated super
unfairly. Giving estimates for software dev is 10x easier than giving
estimates on the usual vague business problems management is facing (the same
management that's always responsible for everything that is wrong, according
to most software developers). Yet I don't hear "management" complaining about
that. Software devs are not royalty.

~~~
redis_mlc
You made 2 major mistakes:

1) > Giving estimates for software dev is 10x easier

No, it's not. If I'm writing software similar to another project, then I can
estimate based on the previous project. But that's rare.

Instead it's something entirely different, otherwise I'd be able to juse reuse
the previous project. In addition, estimating eng. projects like bridges is
easy, because bridges obey physical laws, like gravity. That doesn't apply to
software.

2) > the same management that's always responsible for everything that is
wrong

Ultimately, mgmt. is responsible. However, mgmt. being at the apex can and do
bury their mistakes, no matter how large. As we found out in 2008, there is no
criminal penalty for mgmt. stupidity, regardless of how extreme.

A case in point is Boeing. They kill 350 passengers and damage America's trade
balance, yet their new CEO is from the same board that was responsible. Mgmt.
has no accountability, in the US anyway.

