This article annoyed me. Not because I think it overestimates any of the difficulties, but it condescendingly compares against "standard software engineers" as

This article annoyed me. Not because I think it overestimates any of the difficulties, but it condescendingly compares against "standard software engineers" as if their problems are so much easier and lack additional dimensions beyond algorithm and implementation. It doesn't help that they call N^4 "exponential". Long debugging cycles are not new. In fact, the field started out that way, when computers were slow enough that even a single edit-compile-run cycle could take hours (or days and some political capital, if you go back far enough). Even today, long debugging cycles are far from being restricted to ML, especially for failures that are only seen intermittently and in production. Performance mattering is not unique to ML. Obviously. Data issues are not unique to ML. Anytime you need to run against a "representative workload", you'll bump into them. Heck, anytime you run against a large test suite you'll run into issues with the quality of the comparison data, especially if the tests are long in the tooth. Furthermore, anything you're doing statistics on in general is going to bump into data issues—unless doing statistics is automatically ML? ML lacks various other dimensions of difficulty. Distributed systems. Web browsers that need to execute arbitrary code that hasn't been written yet. Backwards compatibility. Forwards compatibility. In-production databases. Cross platform development. Power usage optimization. Concurrency (ML can have this, but it doesn't always need to, and it can be in the "embarrassingly parallel" bucket). Deep dependency graphs. The author thinks ML development is hard because that's what they work on. They are but a grasshopper.