Effectively, many problems do not have formal "correct" solutions which can easily be applied. One can spend an unbounded amount of time maintaining data-integrity or improving uncertainty handling. As you add more people familiar with this depth to the team, the "best/correct approach" becomes harder to achieve. In the end, a naive estimate of uncertainty is likely about as valuable to the customer as a formal estimate in most problem domains.
"Avoid ML" can easily be code for avoid ambiguous research oriented tasks while building an industrial project, or alternately "don't trust that a magic algorithm will solve your customer problem".
This is not "How to do ML". It's a very much more interesting question "How to build products that can be extended with ML later." I wouldn't even know how to Google for this!
Very interesting. Thank you so much.
Agreed this usually makes sense. My only qualm is that I've seen many systems developed by teams without any ML experience develop tools that (1) throw away or don't maintain data integrity and (2) cannot rank or handle uncertainty in the underlying data. These systems often bake in heuristics that cannot be validated and it's very difficult to change them later. Users feel like they are losing something if you migrate from a tool that automatically chooses the best option for them to one where they need to choose among 5 alternatives, for example, even if that "best option" was actually just noise.
I think the spirit of "avoid machine learning" is great, but I do think having some forethought about how ML might integrate into the system later on is pretty important.