I think we need to organize behind ā€œmove slow and fix thingsā€.

A pattern I’m seeing in my job and my job search is that the tech industry is still under the illusion that ā€œmove fast and break thingsā€ is right, even though we are surrounded by mountains of evidence to the contrary.

Somehow we need to break the chain.

I don’t think I’m alone in this.

A cursory web search shows support for this approach among the business crowd.

https://hbr.org/2019/12/why-move-fast-and-break-things-doesnt-work-anymore

Why ā€œMove Fast and Break Thingsā€ Doesn’t Work Anymore

Over the next few decades, agility will not come from speed; it will come from the ability to explore multiple domains at once and combine them into something that produces value. This means computer scientists working with cancer scientists, for example, to identify specific genetic markers that could lead to a cure. This change will be profound and we will need to rethink old notions about how we compete, collaborate, and bring new products to market. Here are three key shifts.

Harvard Business Review
@requiem Move fast and break things. That is the battle cry of the SiliconTechBrothers to get rid of all responsibility. And a sales pitch. Naomi Klein wrote about it in her book "No Logo". The TechBrothers have read it and implemented it 1:1.
@requiem 2019 article demonstrates that people moving fast ain’t got time to read anything šŸ˜”

@t_var_s @requiem

So much so, that they had to abbreviate the phrase ā€œRead the Fucking Manualā€ so they didn't have too.

@requiem I also think the article is not good and throws a lot of stuff just in the discussion. I do not feel that quantum computing will affect our development work in the near future a lot.
Also, to deliver something fast to a customer and then iterate over it to make it prefect for the requirement is the absolute best way of delivering good software. What I think though, is that we need way less of "what if when" stuff before and way more time to "make it great". My xp in over 300+ projects.
@requiem A pattern I very often see, is that a PO in between (on customer side) makes things worse. You need the feedback of the people who need to work with the software and collaborate with them as close as you can. If they like it, it is a success for the PO and the project will be successful.
For a product driven development the same approach is also key. Do early beta tests and value the feedback you get. Still - give everybody the safety and the time and room to shine.
@requiem "Slow is smooth, and smooth is fast", or if you prefer "cars have brakes so they can go faster".

@requiem The assumption that "market forces" are the best guide for software (so no intentionally planned development is needed) is just so misguided.

The ideal outcome of capitalism are people like Elon Musk or Donald Trump: self-serving narcissists who don't even care about their own families.

Do we really want our software to be like them?

@requiem too few people care about evidence, sadly.
@requiem @metasomite The trouble is that that’s hard work. It’s sexy to do whatever you want and have it work out in the end. It takes wisdom to understand that the world is advanced through small, marginal gains that eventually add up to helping somebody. Move slow and fix things is the way. It just needs better PR.
@requiem @Kayla ā€œMove fast and break thingsā€ is great for alpha. When it makes it to customers though… you’re breaking stuff that isn’t just yours any more.

@requiem My best argument: Facebook - who coined the term - themselves abandoned "Move fast and break things" a decade ago:

> On May 2, 2014, Zuckerberg announced that the company would be changing its internal motto from "Move fast and break things" to "Move fast with stable infrastructure" [Wikipedia]

https://www.businessinsider.com/mark-zuckerberg-on-facebooks-new-motto-2014-5

Mark Zuckerberg On Facebook's New Motto

Facebook is growing up.

Insider
@requiem @KirillOsenkov
Addendum for Microsoft - if it ain't broke then don't "fix" it! No, it's fine, we like it the way it is - DON'T TOUCH IT!
@requiem I keep talking in #Drupal about how we should be refactoring, cleaning up our APIs, improving DX. But people care about shiny new features, not code gardening :(
@requiem you are definitely not alone. It’s a fine paradigm for prototyping, but when it moves out of prototype and into production, moving slower and not breaking things provides a valuable stable experience. I want reliability from the things I buy. Broken is useless to me.

@requiem The fact that "move fast & break things" was ever pitched as a virtue, let alone a default, is a perfect example of the gold-rush-era of web development.

A time where you could run into the hills, fall on your face, and still hit gold - but the people that did thought the frantic scramble was somehow responsible for the success. Not that "the land full of gold is currently untapped so being first counts right now - but won't for long".

"my madness got me wins, *I* did that!" Nah.

@requiem I think we also need to figure a way to fund the "move slow and fix things" movement from the "move fast and break things" techbros who's ketamine fueled tech benders have landed us in this situation.
@requiem We've been saying this in the #fedtech / #civictech sphere for a while now. Obligatory link to @krusynth's shop for all your "move carefully and fix things" gear needs: https://billhunt.dev/shop/
Shop

Personal website and blog of Bill Hunt

Bill Hunt

@mogul @requiem

Here to echo the recommendations of checking out @krusynth’s effort to change the narrative

@requiem It is still the same stupid error of managers, 'there is no time to do it properly but there is always time to redo, repair or patch.'
@requiem unfortunately you need to get paid. And the people dispensing the money are mostly assholes. So you need to work for them at some point

@requiem Capitalism incentivizing short term growth over long term stability, companies not caring about the damage they cause, an insulation from consequences for the powerful, hasty trend-chasing with a fear of being too late to capitalize and tech bros buying too much into their own mythologizing

what a terrible combination

@requiem

Narrator: They were not alone.

@requiem One of the most disheartening phrases in the English language is "Well, we've always done it like this!".

@requiem

Even better. Move slow enough to do it right the first time so when you need to you can fix things.

@requiem can we say move steady instead?

It’s all relative of course, but you can move at a sustainably quick pace if you focus on the process and structure that supports it

@requiem

I don't think you are alone either. I’m old enough to remember when ā€œmove slow and fix things" was the way. Lately I’ve been stuck in this endless loop of moving too fast and breaking too much.

It has to stop.

amirite @rtp

@requiem Have you seen @krusynth’s ā€œMove Carefully and Fix Thingsā€ sticker?
@requiem @krusynth annnnnd I just saw the rest of the thread saying the same thing
@civicwhitaker @krusynth I have not, but it sounds cool šŸ˜Ž
@requiem I admit I'm outside of this, but I think they could still "move fast," etc, if they were more interested in cleaning up as they go, at the same time. more like making breakfast than making noise.
You know?

@requiem @mastodonmigration

So much could be accomplished if Wall Street emphasis on Growth over any other metric and quarterly earnings reports were valued less than merely staying in the black.

You're not. But we need to realise this is about marketing. "Fast and easy" is much easier to sell than "hard and painstaking". So we have to be better at selling, better at copywriting and marketing strategy, than the other team.

Unfortunately most people on our (?) team react really poorly to words like "selling", "copywriting" and "marketing". And they have no strategic sense whatsoever.

@requiem I put "move slow and mend things" as the subtitle on my resume several years ago. I figure if it turns potential employers off, then good riddance.