I think a large part of the problem is that the Tolstoy "All clean data is clean in the same way, but all dirty data is dirty in its own way" riff is itself an

I think a large part of the problem is that the Tolstoy "All clean data is clean in the same way, but all dirty data is dirty in its own way" riff is itself an over-simplification. In practice, "clean" just means "fit for my purpose" and "dirty" just means "unfit for my purpose". If counting the instances of a particular string is all you need to do (and it quite often is) then de facto all data is "clean", as you can get the job done with grep. If, on the other hand, you require a relational database with strict primary and foreign key definitions and NULL limitations, then you're gonna have to put a lot more work into scrubbing. Added to that, the more stringent the defition of "clean" you're working with, the more you're going to have to deal with trade-offs. E.g. what do you do with missing required data field values? Loosen the requirement? Add defaults? Dump those rows? And what do you do with data that makes no sense, e.g. where end dates come before start dates? What if you need to anonymize the data to meet data privacy requirements? Is rounding dates to the nearest month or year fine, or will it render the data useless? There are recurrent problems, and recurrent solutions, and the author is absolutely right to say that more open source work should be done in that area. But due to complexity and inconsistency of the definitions of "clean" and "dirty", we will unfortunately never get to the point where we just feed some library the path to an arbitrary dirty data directory, press enter, go off to grab a coffee and come back to find our freshly cleaned data waiting for us.