Live data from Hacker News

Why “Move Fast and Break Things” Doesn’t Work Anymore

hbr.org

41–50 of 124 posts

Re: Why “Move Fast and Break Things” Doesn’t Work Anymore

#41

Please, someone tell the geniuses at Harvard business that no one ever used "Move Fast, break things" for chips. Having been in the industry long enough, I've seen plenty a launch date moved, and chip-respins executed in favor of risking a recall of hardware from the field. It's only non-critical, consumer/casual software/applications that can afford to move fast, and break things. Your bank, or medical records, or e…

>Your bank, or medical records, or even traffic light controls simply cannot move fast and break

Don't tell the banks and financial industry that (looking at you, Equifax).

Re: Why “Move Fast and Break Things” Doesn’t Work Anymore

#42
post #39

Earlier quoted context omitted.

I agree. If anything, tinkering and iterating is the best approach to deal with complexity, which the author says will emerge from the new technology.

oh yea... for next sprint, let's green-blue roll out the update for this new cancer treatment and a/b test it on some patients so we can iterate.

>> a/b test it on some patients

What do you think placebos in clinical trials are??

Re: Why “Move Fast and Break Things” Doesn’t Work Anymore

#43
I move that the article definitely touches upon a critical topic but fails to nail it due to a too-narrow yet too-peripheral account.

Consider this:

> Over the coming decades, however, agility will take on a new meaning: the ability to explore multiple domains at once and combine them into something that produces value. We’ll need computer scientists working with cancer scientists, for example, to identify specific genetic markers that could lead to a cure. To do this, we’ll need to learn how to go slower to have a greater impact.

This "working with, across domains" mantra underlies the entire article. It's called transdisciplinarity — if not of individuals, of teams.

Guess what. That's how we've done any sector for the longest of times. You start with self-made specialists, they grow the field, which then touches other fields, and before you know it, a "normal" business has several functions: accounting, sales, legal, marketing, production, etc.

Tech is new, and tech is geeky — the greatest among us estimate that no more than 1~5% of the population has enough interest to enter and remain in the field.

Transdisciplinarity is usually a major key to unlock hard problems, indeed. As more and more engineers enter the tech field coming from previous careers, armed with domain knowledge, the quality and "relevance" of tech features improves, no doubt about it — I think music and the arts in general, observed over the last 50 years or so, is a strong illustration of that.

> These new technologies are far too complex for anyone to develop on their own. That’s why we can expect the basis of competition to shift away from design sprints, iterating, and pivoting to building meaningful relationships in order to solve grand challenges.

This literally confuses goals with methods. Agile never told you what to do or why you do it, it's just a "small method for small teams to work better/faster, to manage complexity". Grand challenges don't get automagically solved because they're big and involve many people from many fields.

The "far too complex for anyone to develop on their own" part is more telling of a philosophical bias: we tend to either see the world as "too complicated to be explained" (as the HR author) or "too simple to be worth wasting time to intellectualize it" (this is the general entrepreunarial mindset, to go at things from action even if it's not entirely clear mentally; the opposite mindset, which is mine, is more of a research ethos, an observer / thinker.)

Transdisciplinarity is also not a new thing. It's just the latest trend to kick in on the road to progress, it's a pendulum from hyper-specialization (high verticals) to holistic solutions (big horizontals).

Consider philosophy, human beings sprouting ideas, software engineering for the mind. An idea appears somewhere, in a group, in some space-time. It starts localized, vertical. The taller is gets (i.e. the highest its worth and the strongest its implementation, its relevant rooting at many levels of the stack), the wider it may eventually resonate, spread, horizontally towards other fields, other domains, other spacetimes and cultures. "Don't kill thy neighbor" is kind of such a piece of software that most of us have installed. But look how philosophy generates ideas: usually not in isolation, rather from looking at the world. The best philosophers, imho, are those who speak from experience (typically not career-philosophers, rather doers, goers, people who act and only then speak).

Case in point: after a few thousand years of thinking and transmission, philosophy is part of everything we do, are.

Technology (in the current modern sense, computing, electronics, etc) is like that, it's a big vertical with tremendous horizontal reach. It will become, like philosophy, like any valuable improvement to human condition, a massively transdisciplinary activity.

Re: Why “Move Fast and Break Things” Doesn’t Work Anymore

#44
"Move fast, break things" never worked in any meaningful way, especially in AWS. It's a garbage philosophy repeated by idiots who don't support business applications driven by software on a global (enterprise, mission critical, always-on) scale. Literally no one at Amazon practices this idea, except the idiots who think that launching pre-alpha garbage into production because of poorly conceived re:invent promises is an acceptable business model that builds customer trust (spoilers, it doesn't). Source: worked there, did that.

Re: Why “Move Fast and Break Things” Doesn’t Work Anymore

#47
post #8

Earlier quoted context omitted.

Ask Mark Zuckerberg, Travis Kalanick or Brian Chesky.

It might have worked for Travis Kalanick, but can we really say that it worked for Uber?

Depends on how you define "Uber". If you mean the construct and it's continued existence, then the jury is still out on that. For all the early investors and employees (the ones that facilitated the "move fast" attitude), it looks like it worked pretty well.

Re: Why “Move Fast and Break Things” Doesn’t Work Anymore

#48
Whenever I see articles like this or about frameworks like the Cynefin framework I cannot help but to see it like any mathematical optimization problem. If the solution is simple to see you just jump to the solution. If it is more complicated but you have good practices / know the gradient (“know in what direction you are going”) and the problem is well behaved, you can iterate quickly and reach and expect to find an optimum. But if it is more complex and you don’t know I what direction to go / don’t have a gradient you need to do try lots of different experiments in parallel also.

And the more costly an iteration is the more important it is with multiple perspectives to get as much data into the different experiments from the beginning as opposed to randomly selecting things to try out and seeing what happens.

Re: Why “Move Fast and Break Things” Doesn’t Work Anymore

#49

Please, someone tell the geniuses at Harvard business that no one ever used "Move Fast, break things" for chips. Having been in the industry long enough, I've seen plenty a launch date moved, and chip-respins executed in favor of risking a recall of hardware from the field. It's only non-critical, consumer/casual software/applications that can afford to move fast, and break things. Your bank, or medical records, or e…

"Move fast, break things" works well when iterating quickly and cheaply in an unknown space. Chip design is not one of those cases.

To the OP’s point, I think the claim is that this doesn’t work well if the unknown space is safety critical.

Re: Why “Move Fast and Break Things” Doesn’t Work Anymore

#50
post #49

Earlier quoted context omitted.

"Move fast, break things" works well when iterating quickly and cheaply in an unknown space. Chip design is not one of those cases.

To the OP’s point, I think the claim is that this doesn’t work well if the unknown space is safety critical.

Yes, that would go under "cheaply" in my previous comment.
Post reply on HN