6 ms·

People like to think that the alternative to "move fast and break things" is "move slowly and not break things" but it's not, it's "move slowly, break things an

People like to think that the alternative to "move fast and break things" is "move slowly and not break things" but it's not, it's "move slowly, break things anyway, then take days to resolve the problem because you never learned how to move fast".

eckza 4y ago
That's just not true. Moving faster does not mean moving more effectively. Frantic activity should not be mistaken for progress. I'm OK with the FAA taking "days to resolve the problem" if it means that nobody dies. For what it's worth, my team and I are partial to "move carefully, and tend things".
- justinsaccount 4y ago
  "Moving faster" doesn't mean "frantic" either. Who said frantic?
  - haswell 4y ago
    Frantic is often a natural outcome of “moving faster” when the environment one is moving in is not conducive to that speed of movement. In my experience, this tendency towards frantic is multiplied the larger and more complex the organization and architecture becomes. The entire point of “move fast” in software circles is to leave behind the constraints of legacy tech and management practices in favor of building something “better”. In a mature org that grew up before these ideas were mainstream, maybe one or two teams can manage to move faster, but invariably they end up depending on other teams, who in turn depend on deeply ingrained and established company culture and procedures. We can talk about why those impediments are a Bad Thing, and I wouldn’t advise a consumer startup to adopt those methodologies in 2022, but there’s still the harsh reality that where they exist, “just move faster” doesn’t help much more than telling a depressed person to “just do cardio every day”. There’s often a lot of inner work that’s gotta happen to make way for the new. The only way I’ve seen this sort of work in a large org is when a brand new “emerging tech” group is spun up and given autonomy to work outside of the legacy norms. This is not perfect either, and seems much better for greenfield projects. When applied to deeply entrenched legacy systems, all of the problems mentioned above come to a head. This also creates a weird in/out group dynamic which tends to further stratify the old tech and widen the gap between the old practices and the new. In the context of this particular conversation though, I think the concept of “move fast” has lost all meaning and has little to offer for an org like the FAA.
DonHopkins 4y ago
You act like "moving fast" is all you need to know to "move fast". As if it's simply the skill of making time move faster, and you don't need any other skills than that, because once you've broken the laws of physics and changed the speed of time, everything just works faster without any differences or consequences. Do you watch a lot of Superhero movies? You should work smarter, not harder. Just turn up your smart knob. But why didn't you ever think of that before? Probably because you had your smart knob turned all the way down.
- justinsaccount 4y ago
  I'm not sure what point you are trying to make. Physics? super heroes? knobs?
  - DonHopkins 4y ago
    My point is that "you never learned how to move fast" is just as glib and patronizing and useless advice as "work smarter, not harder". ESPECIALLY if millions of people's lives and fortunes are at stake, as in this case with air traffic control.
- shuntress 4y ago
  Slow is smooth and smooth is fast.
avgDev 4y ago
When I hear "move fast and break things", I am reminded of a guy that I worked with. He delivered work fast......full of bugs...0 planning...and his daily ritual was to just keep patching the "pile of shit" he put together. He has now moved on and we sometimes chat, he works for a huge corp, still sucks at writing SQL.
- justinsaccount 4y ago
  And as I said, people think the alternative to "fast, full of bugs, 0 planning" is automatically "slow, no bugs, lots of planning" but it's often "slow, lots of planning, just as many bugs"
  - avgDev 4y ago
    When you are in a complex spiderweb you simply cannot move fast. If you are moving fast you are not looking at everything and it will blow up in your face.
    - justinsaccount 4y ago
      True.. which is why you want simple systems that are easy to understand and iterate on.
      - DonHopkins 4y ago
        The worldwide air traffic control system is not simple or easy to understand and iterate on. And that's not because it was designed by idiots, or that you're so much smarter and more experienced and a vastly better programmer than the combined efforts of everyone in the world working on air traffic control, as you seem to be implying from your comfortable armchair. Are you proposing the entire world simply give up air travel, because government regulations and industry standards and the laws of physics and chaos theory prevent you from having the simple easy to understand air traffic control system you envision?
        4y ago
cloverich 4y ago
Change is the most common reason for breaking things. Moving fast means more broken things, hence the slogan. The alternative is indeed move slow, break things less often. It's a bad strategy when you NEED a LOT of change. But if you don't NEED a LOT of change, and you do need a lot of stability, it seems perfectly valid?
- justinsaccount 4y ago
  So for the things that don't need a lot of change, what are some characteristics of the system? Does CI/CD exist? Does CI even exist? Are deployments automated? Is data sanity checked before loading? Is there a development environment? Do things like hourly snapshots exist? Can you easily provision a replacement system from scratch and restore data from a known good snapshot? Or, is every process manual, slow, and error prone because there's never been a need to move fast. Look at this one sentence in the article: > In the overnight hours of Tuesday into Wednesday, FAA officials decided to shut down and reboot the main NOTAM system -- a significant decision, because the reboot can take about 90 minutes, according to the source. So they do a reboot, that takes 90 minutes for some reason, and then that didn't even fix the problem. Their system that needs a lot of stability is now broken.

eckza 4y ago

That's just not true. Moving faster does not mean moving more effectively. Frantic activity should not be mistaken for progress. I'm OK with the FAA taking "days to resolve the problem" if it means that nobody dies. For what it's worth, my team and I are partial to "move carefully, and tend things".

justinsaccount 4y ago
"Moving faster" doesn't mean "frantic" either. Who said frantic?
- haswell 4y ago
  Frantic is often a natural outcome of “moving faster” when the environment one is moving in is not conducive to that speed of movement. In my experience, this tendency towards frantic is multiplied the larger and more complex the organization and architecture becomes. The entire point of “move fast” in software circles is to leave behind the constraints of legacy tech and management practices in favor of building something “better”. In a mature org that grew up before these ideas were mainstream, maybe one or two teams can manage to move faster, but invariably they end up depending on other teams, who in turn depend on deeply ingrained and established company culture and procedures. We can talk about why those impediments are a Bad Thing, and I wouldn’t advise a consumer startup to adopt those methodologies in 2022, but there’s still the harsh reality that where they exist, “just move faster” doesn’t help much more than telling a depressed person to “just do cardio every day”. There’s often a lot of inner work that’s gotta happen to make way for the new. The only way I’ve seen this sort of work in a large org is when a brand new “emerging tech” group is spun up and given autonomy to work outside of the legacy norms. This is not perfect either, and seems much better for greenfield projects. When applied to deeply entrenched legacy systems, all of the problems mentioned above come to a head. This also creates a weird in/out group dynamic which tends to further stratify the old tech and widen the gap between the old practices and the new. In the context of this particular conversation though, I think the concept of “move fast” has lost all meaning and has little to offer for an org like the FAA.

DonHopkins 4y ago

You act like "moving fast" is all you need to know to "move fast". As if it's simply the skill of making time move faster, and you don't need any other skills than that, because once you've broken the laws of physics and changed the speed of time, everything just works faster without any differences or consequences. Do you watch a lot of Superhero movies? You should work smarter, not harder. Just turn up your smart knob. But why didn't you ever think of that before? Probably because you had your smart knob turned all the way down.

justinsaccount 4y ago
I'm not sure what point you are trying to make. Physics? super heroes? knobs?
- DonHopkins 4y ago
  My point is that "you never learned how to move fast" is just as glib and patronizing and useless advice as "work smarter, not harder". ESPECIALLY if millions of people's lives and fortunes are at stake, as in this case with air traffic control.
shuntress 4y ago
Slow is smooth and smooth is fast.

avgDev 4y ago

When I hear "move fast and break things", I am reminded of a guy that I worked with. He delivered work fast......full of bugs...0 planning...and his daily ritual was to just keep patching the "pile of shit" he put together. He has now moved on and we sometimes chat, he works for a huge corp, still sucks at writing SQL.

justinsaccount 4y ago
And as I said, people think the alternative to "fast, full of bugs, 0 planning" is automatically "slow, no bugs, lots of planning" but it's often "slow, lots of planning, just as many bugs"
- avgDev 4y ago
  When you are in a complex spiderweb you simply cannot move fast. If you are moving fast you are not looking at everything and it will blow up in your face.
  - justinsaccount 4y ago
    True.. which is why you want simple systems that are easy to understand and iterate on.
    - DonHopkins 4y ago
      The worldwide air traffic control system is not simple or easy to understand and iterate on. And that's not because it was designed by idiots, or that you're so much smarter and more experienced and a vastly better programmer than the combined efforts of everyone in the world working on air traffic control, as you seem to be implying from your comfortable armchair. Are you proposing the entire world simply give up air travel, because government regulations and industry standards and the laws of physics and chaos theory prevent you from having the simple easy to understand air traffic control system you envision?
      - 4y ago

cloverich 4y ago

Change is the most common reason for breaking things. Moving fast means more broken things, hence the slogan. The alternative is indeed move slow, break things less often. It's a bad strategy when you NEED a LOT of change. But if you don't NEED a LOT of change, and you do need a lot of stability, it seems perfectly valid?

justinsaccount 4y ago
So for the things that don't need a lot of change, what are some characteristics of the system? Does CI/CD exist? Does CI even exist? Are deployments automated? Is data sanity checked before loading? Is there a development environment? Do things like hourly snapshots exist? Can you easily provision a replacement system from scratch and restore data from a known good snapshot? Or, is every process manual, slow, and error prone because there's never been a need to move fast. Look at this one sentence in the article: > In the overnight hours of Tuesday into Wednesday, FAA officials decided to shut down and reboot the main NOTAM system -- a significant decision, because the reboot can take about 90 minutes, according to the source. So they do a reboot, that takes 90 minutes for some reason, and then that didn't even fix the problem. Their system that needs a lot of stability is now broken.