[phtrivier]

Impossible to disagree with the author, and yet something seems missing in the discussion... Let me check:

Ctrl-F, 'deadline'

0 result.

Oh, yeah, that's what missing from the discussion.

And without any trolling, I'm curious about what the author would have to say about this matter.

Not all "need for speed" comes from a vacuum. Is it always legit ? Should we push back ? Sure.

Do we always meaningfully, practically, realistically have a choice anyway ?

[aswegs8]

I think the author is having a kind of idealistic, relaxed view of work. Moving quickly, even if you break things, has a clear advantage over being perfectionistic, waiting to get feedback, building things that are not needed.

These are obvious lessons of agile management. Even if they are not absolute, maybe that post is meant as some kind of relative statement, in general, speed is a good thing. More speed than you are comfortable with.

[dolni]

> Moving quickly, even if you break things, has a clear advantage over being perfectionistic, waiting to get feedback, building things that are not needed.

The entire point of slowing down is so you don't do this. Understand the problem well first, so you don't waste time building something that was never viable in the first place.

The author isn't advocating for perfect. You have to understand the problem well enough to know what all of the critical assumptions are. Some assumptions will derail an entire project if you get them wrong. Others will be a minor inconvenience, at worst.

In software, having a solid handle on future architecture means you can speak to how unanticipated new features fit in. You know what parts you can skip for now, and have it not be a big deal.

I've started to wonder if many of the people obsessed with speed lack capability. If you can't build something well, you can try building something poor quickly. This certainly applies to my current employer.

[rglover]

Author here. This is the correct interpretation of what I was getting at.

[rglover]

I'm the author.

Deadlines are artificial constraints (typically, some deadlines are unshakable—eg "we have to launch the payload when conditions are clear") that, imo, distract from the actual goal or task at hand.

Sadly, a deadline is more often used as an excuse to rush, and not because the deadline itself is of material consequence (e.g., meeting a vendor's production deadline is unshakable).

Instead, the more common reality is that someone in a position of limited agency uses the deadline as a sort of mental whip. This may get a result faster, but rarely is the work that was rushed solely to meet a deadline the best the team/individual was capable of. More often, you get a broken mess that now necessitates wasting more time later cleaning it up (this is the part I think traps a lot of people; it's a stealing from Peter to pay Paul situation).

When I've discussed this in the past, most misinterpret my point through too binary a lens. This isn't some hippie dippie idealist "just, like, do whatever maaan" kind of take.

Instead, it's a suggestion for those in an environment that's always "moving fast" but rarely if ever hitting the mark. This leads to papering over the obvious problem: the team or individual responsible for the bad work is rarely someone of pure incompetence and more often is just under completely imagined pressure that doesn't exist (beyond the confines of the minds involved).

I'm not naive, of course you can't blanket apply this line of thought to every situation (especially in corporate America). I'm more so angling at "have you considered that rushing is the reason everything you ship falls apart and doesn't meet its goals?"

Case in point: FedEx deployed some new dashboard software for their employees doing package handling. I came in to drop off a MacBook I was sending in for repair. While scanning it in, the system just broke (in the "it ain't doing the thing no more, ma" sense). The clerk was able to manually scan it, so skipped the system and gave me a receipt. A week later, Apple never got the laptop. I start calling around frantically, now having to do work I shouldn't be doing. It was determined that the label printed (the one I got a receipt for) wasn't the "correct" label to scan (that was hidden under another label already on the box). This led to weeks of unnecessary phone calls re-explaining the situation to various employees, now arguing with me about a mistake FedEx made.

Eventually, Apple called it a mulligan after a month and sent me a new laptop.

My point: whatever caused the FedEx team to rush had a ripple effect of wasting inordinate amounts of time and costing Apple $5K. Why? Because whoever built that dashboard software rushed and made an otherwise simple idea into a half-working, frustrating mess. This is the type of situation I have in mind when I tell others "we need to slow down."

Like I alluded to in the post, it's not about moving slow as a matter of psychological comfort, but as a means to avoid creating messes in the present (and future) in service of an arbitrary deadline that's less rooted in necessity and more so in fulfilling the ego of whoever is in charge. That's a tough pill to swallow, I get it, but like most things, the actual problem isn't the process or reality, it's the human mind convincing itself of things that just aren't true.

[jeremyjh]

Fedex Returns is just about the least competent product technology entity I've ever encountered and this migration was a garbage fire even by their low standards. I doubt if they could have gotten it right if they spent 10 years on it, and its entirely possible they did do that.

[latexr]

Most deadlines are artificial and self-inflicted. The author is not advocating that if you have a literal fire consuming half your home that you should sit down on the floor, ponder your possibilities, schedule a few calls for discussion, then send a few messages on Slack to decide what to do; of course some things are more urgent than others. The author is calling out a “speed cult”; they’re not making an absolutist argument but the exact opposite, advocating for “the discipline of judgment”.

[jcelerier]

> Most deadlines are artificial and self-inflicted.

most software in the world is built by consulting companies for external customers and under their customer's deadline, thus not self-inflicted

[ricardobeat]

When I worked in consulting, the majority of deadlines were still self-inflicted, based on estimates provided by us.

If you fall into the fast -> unexpected -> iteration -> alignment cycle the author mentions, those estimates tend to be based on the 'fast' part only; that closes deals.