3 ms·
A perfectly reasonable alternative, which is not really any more mathematically difficult nor harder to implement in software, is outlined in several sections o
by p4wnc6 11y ago
A perfectly reasonable alternative, which is not really any more mathematically difficult nor harder to implement in software, is outlined in several sections of the Kruschke paper that I linked.
In general though, I would dispute a lot of your claims about what industry statisticians (or "data scientists" if you want to use a buzzword) need to do. One of the primary jobs of industry statisticians, it would seem, should be to slow everyone down on purpose, because everyone is in such a rush to get "insight" and "actionable information" and to get some sweet data viz of some KPIs that they are doing horribly shoddy statistics, and mutating the craft of statistics overall into some kind of shoddy data journalism / data story telling circus where the careful avoidance of statistical pitfalls doesn't seem to matter to anyone.
- mabbo 11y agoThe problem with slowing down is that there are 10 competitors who are not going to slow down. Each is trying something different, and we have to pick which option we want to do. What management need is the answer to what to do, as quickly as possible. If they pick the wrong answer because of bad statistics, the company loses to the competitor who randomly picked the right answer. If the company makes no decision quickly enough, the company loses to the competitor who quickly randomly chose the right answer. So given those constraints (the need for accuracy and the need for answers as soon as possible) what is the best way forward? Remember: they don't pay us because math is fun, they pay us to solve their problems.
- p4wnc6 11y agoThis is false. See Chapter 4 of Peopleware. There is not actually a trade-off between quality and speed of delivery, especially not when you look medium- or long-term, but also not even in short-term. When you incentivize people to solve a problem in a high-quality way, they tend to also solve it faster and with fewer defects than when they are told to prioritize speed. Also, none of this is nearly as binary as your comment makes it seem to be. Yes, you might lose a little in the short-term to a faster, but more error-prone, competitor. But as long as the loss isn't so severe that you become insolvent, then you might live to see the day when all of the competitor's errors and sloppy work come home to roost and they fail spectacularly. In general, doing it wrong but fast is pretty worthless, investors and customers will catch on to you and bail, and only the highest level of management will have insulated themselves from the losses that result. Working for a steadier company that prioritizes building a name based upon actual quality, and is willing to tell customers or investors no when they must do so, to regulate feature creep, ensure high quality standards and accuracy, and so forth, is not only much more rewarding, but also more likely to lead to stable income. I think the type of binary, winner-must-take-all-as-soon-as-possible thinking is very destructive. It's not a useful mental model of how this stuff actually works, but because so many managers believe that it is, they engage in all kinds of unnecessary and self-destructive anti-quality patterns, and they end up damaging everyone in a tragedy of the commons sort of way.