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.
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.