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".
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.
ESPECIALLY if millions of people's lives and fortunes are at stake, as in this case with air traffic control.
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".
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.
He has now moved on and we sometimes chat, he works for a huge corp, still sucks at writing SQL.
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?
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.