undefined | Better HN

0 pointsadvael1y ago0 comments

Of course prioritizing shipping more features is going to ship more features. The whole point of prioritizing engineering is to trade off some speed for other things, like your shit not breaking. The incentives in most companies produce catastrophic failures because the mechanisms for punishing individual failure on speed metrics (the easiest metrics and thus the only metrics most organizations know how to or care to measure) are powerful and numerous but the organization-level incentives don't adequately punish the kind of catastrophic failure we are seeing constantly. That cost is externalized from the organization that failed. Their customers and those customers' customers and anyone affected by the whole world being made of brittle nonsense pay the price and have meager recourse if any. If your reason for prioritizing correctness over speed is because you believe that this will eventually produce more speed, I don't know what to tell you. That's possible and a really nice outcome when it happens, but it's not the point of doing it and it's not the typical benefit

0 comments

klodolph1y ago

Here’s how I’ve seen this play out at some larger, more bureaucratic companies. (This is just an example, it doesn’t have to play out this way.)

You start by moving fast and putting out features. Then something breaks in a high-profile way and the hammer comes down. The environment changes and people start avoiding blame. Some of the effects I’ve seen:

- You bring more people into meetings (diffuses the blame when something goes wrong, but slows everything down)

- You demand more detailed requirements (makes development more predictable, but good designs tend to evolve and do a lot of discovery)

- Tedious work doesn’t get automated, and your headcount requirements go up (because tedious work is predictable, and automation is a risky project)

Eventually, somebody in senior leadership (hey, I said “larger company”) notices that the entire org has basically slowed to a crawl and is constantly demanding more headcount, and they have to go in and fix things. Or they decide to axe a bunch of projects, or reorg, or something else.

I want to emphasize that this is a possible way that the story plays out, not that the story always plays out this way.

MereInterest1y ago

> Of course prioritizing shipping more features is going to ship more features

I mean, I'm not entirely sure on that. Prioritizing shipping features may make a codebase be impossible to understand, so that any additional features take longer and longer to implement. Prioritizing design may make a codebase be easier to understand, such that each new feature can be added with breaking existing functionality.

There's a quote I like from Jonathan Livingston Seagull: "It's strange. The gulls who scorn perfection for the sake of travel go nowhere, slowly. Those who put aside travel for the sake of perfection go anywhere, instantly."

j / k navigate · click thread line to collapse