Machine Learning Is No Place To “Move Fast And Break Things” – Forbes
“It is much easier to apologize than it is to get permission.”
The hacking culture has been the lifeblood of software engineering long before the move fast and break things mantra became ubiquitous of tech startups [1, 2]. Computer industry leaders from Chris Lattner  to Bill Gates recount breaking and reassembling radios and other gadgets in their youth, ultimately being drawn to computers for their hackability. Silicon Valley itself may have never become the world’s innovation hotbed if it were not for the hacker dojo started by Gordon French and Fred Moore, The Homebrew Club.
Computer programmers still strive to move fast and iterate things, developing and deploying reliable, robust software by following industry proven processes such as test-driven development and the Agile methodology. In a perfect world, programmers could follow these practices to the letter and ship pristine software. Yet time is money. Aggressive, business-driven deadlines pass before coders can properly finish developing software ahead of releases. Add to this the modern best practices of rapid-releases and hot-fixing (or updating features on the fly ), the bar for deployable software is even lower. A company like Apple even prides itself by releasing phone hardware with missing software features: the Deep Fusion image processing was part of an iOS update months after the newest iPhone was released .
Software delivery becoming faster is a sign of progress; software is still eating the world . But it’s also subject to abuse: Rapid software processes are used to ship fixes and complete new features, but are also used to ship incomplete software that will be fixed later. Tesla has emerged as a poster child with “over the air” updates that can improve driving performance and battery capacity, or hinder them by mistake . Naive consumers laud Tesla for the tech-savvy, software-first approach they’re bringing to the old-school automobile industry. Yet industry professionals criticize Tesla for their recklessness: A/B testing  an 1800kg vehicle on the road is slightly riskier than experimenting with a new feature on Facebook.
Add Tesla Autopilot and machine learning algorithms into the mix, and this becomes significantly more problematic. Machine learning systems are by definition probabilistic and stochastic — predicting, reacting, and learning in a live environment — not to mention riddled with corner cases to test and vulnerabilities to unforeseen scenarios.
Massive progress in software systems has enabled engineers to move fast and iterate, for better or for worse. Now with massive progress in machine learning systems (or “Software 2.0” ), it’s seamless for engineers to build and deploy decision-making systems that involve humans, machines, and the environment.
“A current danger is that the toolset of the engineer is being made widely available but the theoretical guarantees and the evolution of the right processes are not yet being deployed. So while deep learning has the appearance of an engineering profession it is missing some of the theoretical checks and practitioners run the risk of falling flat upon their faces.”
In his recent book Reboot AI , Gary Marcus draws a thought provoking analogy between deep learning and pharmacology: Deep learning models are more like drugs than traditional software systems. Biological systems are so complex it is rare for the actions of medicine to be completely understood and predictable. Theories of how drugs work can be vague, and actionable results come from experimentation. While traditional software systems are deterministic and debuggable (and thus robust), drugs and deep learning models are developed via experimentation and deployed without fundamental understanding and guarantees. Too often the AI research process is first experiment, then justify results. It should be hypothesis-driven, with scientific rigor and thorough testing processes.
“What we’re missing is an engineering discipline with principles of analysis and design.”
Before there was civil engineering, there were buildings that fell to the ground in unforeseen ways. Without proven engineering practices for deep learning (and machine learning at large), we run the same risk.
Taking this to the extreme is not advised either. Consider the shift in spacecraft engineering the last decade: Operational efficiencies and the move fast culture has been essential to the success of SpaceX and other startups such as Astrobotic, Rocket Lab, Capella, and Planet. NASA cannot keep up with the pace of innovation — rather, they collaborate with and support the space startup ecosystem. Nonetheless, machine learning engineers can learn a thing or two from an organization that has an incredible track record of deploying novel tech in massive coordination with human lives at stake.
Grace Hopper advocated for moving fast: “That brings me to the most important piece of advice that I can give to all of you: if you’ve got a good idea, and it’s a contribution, I want you to go ahead and DO IT. It is much easier to apologize than it is to get permission.” Her motivations and intent hopefully have not been lost on engineers and scientists.
Notes & References
 Facebook Cofounder Mark Zuckerberg’s “prime directive to his developers and team”, from a 2009 interview with Business Insider, “Mark Zuckerberg On Innovation”.
 Chris Lattner is the inventor of LLVM and Swift. Recently on the AI podcast, he and Lex Fridman had a phenomenal discussion:
 Hotfix: A software patch that is applied to a “hot” system; i.e., a fix to a deployed system already in use. These are typically issues that cannot wait for the next release cycle, so a hotfix is made quickly and outside normal development and testing processes.
 A/B testing is an experimental processes to compare two or more variants of a product, intervention, etc. This is very common in software products when considering e.g. colors of a button in an app.
 “Software 2.0” was coined by renowned AI research engineer Andrej Karpathy, who is now the Director of AI at Tesla.
Harvard Data Science Review