If you're iterating on your approach to a model, it really is a drag to do a bunch of bullshit in order to run an experiment that's likely to fail and just be thrown out anyways.
If you're shipping that model to production and affecting people's lives, it should really be held to a different standard than the "fuck around and see what happens" experiments.
And this is before we even get into unexplainability of deep neural nets.
Stop behaving like you can fake it and then make it later. The code has already shipped and they’re pressuring you to move on to the next problem. Anything you haven’t nailed down by the time the customer is happy is not going to get nailed down. The time you get is the time it takes. So if you genuinely haven’t gotten enough time, then you need to slow down and take the time now, because there is no after.
There’s only been two times my code could kill someone, and you bet your ass I didn’t deliver it a moment faster than I thought reasonable, and in one of those cases it ended up being fast enough (the other was, in retrospect, already doomed before I got there)
Professional software development has plenty of proofs of concept and "iterating on an approach to a" something. I don't understand what confused state of mind leads anyone to assume that any field of engineering, specially software development, doesn't deal with one off quick and dirty tests.
What really boggles the mind is that any data analyst worth his salt knows very well that he needs to track his inputs to be able to analyse the outputs, thus software development practices are far more forgiving than data analysis ones.
It seems to me that the author just wants to make excuses for shoddy work.
I don't necessarily agree, I think it's more to do with market value of output, but a large number of people feel that way. Where we do always agree is that there are Things Which Must Be Done, even when you don't wanna.
It's more common in the young, but also has a much better prognosis.
In particular I've seen my share of code written by non-developers, and they all make the same classes of mistakes one makes when you have less than a couple thousand hours of focused development work under your belt. Well we can't do that because X, or we don't need that because Y. Oh, okay. Is that why I have to come tow you out of the proverbial mud every couple of months?
Could you humor me and try a few of these things out? I think it'll help.
What people fear most is automated systems that are constructed on wishful thinking, not healthy skepticism. A lot of our processes are about proving to ourselves what we think we already know. There is plenty of code under the AI umbrella for which very conventional unit tests could be written. If you can't use our practices for ML, you'd better drop what you're doing and start developing parity, instead of bullshitting yourselves and everyone else about your exceptionalism.
Code that makes decisions for or about people needs more ceremony and sobriety around it, not less. If you can't do at least as well as a startup (which is a pretty low bar), then we are really in some deep doodoo. But not to worry. The good news is that when the machines take over and we have to hide underground, you'll be the first ones we eat, so you won't suffer long.