The feasibility of buying 292 million tickets (as you mention) is a key barrier: many lotteries (Powerball included) explicitly and deliberately require that tickets must be bought in person. So, just as a matter of time constraints, you'd need a (nontrivial) army.
Rough ballpark: 300 million combos - let's say you buy 6000 tickets/hour (which I think is actually optimistic probably by a full order of magnitude), for 25 hours a day (assume shifts and magic days), you're still looking at 2,000 person-days.
Most of these are for chronic conditions, where people are seeing their doctor on a fairly regular (once every few months) basis. And yeah, at least some patients absolutely do ask, "hey, I heard about X, is that good for me?"
There are of course also the extreme cases of specifically asking for a given prescription, but like the parent mentioned, just having a few patients persistently ask the doc about X is enough of a motivator to get the doctor to pay [marginally] more attention to the doctor-facing literature/ads/sales force.
I like the spirit of that effort, but it has a checkered history; it was born out of input from a private working group without input from the community [1]. I'm fundamentally against this philosophy as an open source advocate.
My understanding is that PLM very much translates to useable knowledge - just for the pharma and PHM folks who mine the backend (which is how they make money). Notably, this is all quite above-board: it's not a "secretly mine people's private medical details" situation, it's "overtly mine people's private medical details in order to help find treatments for their rare disease"...
You are right about that - and I think they are doing something really good (and props to them for being really up-front about how they operate) but unless they can really do something to help patients day-to-day, is seems the participation rate will probably always be small and inconsistent, which means a smaller, less-complete data set that will yield less accurate and useful results.
Again, I like the goal and I did try them but it is not a good user experience or particularly helpful on the individual level so even doing it altruistically really didn't last. To get that kind of rich dataset, you need the user to be highly engaged which means they are really getting something out of it and using it for the primarily selfish reason that it helps them.
Having now had a lot of experience dealing with the medical system as related to complex and chronic diseases, I still find myself really surprised by how little the "consumerization of x" movement has impacted it. Per point of the original article, I shouldn't be. The massive bureaucracy, the regulatory capture, and the general politics of the industry are so all-consuming that there is little time or energy left over for the patients. (disclaimer: yes, there are a ton of amazing individuals working in the industry but even they are, unfortunately, really handicapped by the system itself)
I like ZP (now Gusto), I really do, but their support over time has been lacking (and it feels like it's degrading), and as a customer I'm growing increasingly concerned that they're growing too fast to keep up.
Granted - I'm a tiny account (3 employees). That said, it's frustrating that it takes weeks to get answers to questions (some simple, some less so). When I finally do get someone's attention, the resolution is generally a good one, but it just feels like they're flat-out understaffed on the support side - which is disconcerting when dealing with things like payroll, taxes, etc.
I certainly wish ZP all the best, and perhaps this expansion into new lines of business will help them hire more support staff... but a part of me feels like, "guys, get your house in order first before your start expanding."
Hi Kevin! I'm the community manager over at ZenPayroll. Thanks for taking the time to post.
I can't tell you how sorry we are to hear about this issue and there's no excuse for the delay in our response. Please rest assured that your business (no matter how small) is incredibly important to us. In fact, because your company is small, we especially want to be there to help!
We have been particularly busy lately on the support side, especially with the launch, but again, that's no excuse. We hold ourselves to a certain standard of delight on product, support, and overall customer experience and we didn't deliver on that for you. We should and can be better.
We want to let you know we've done a ton of hiring lately, in addition to opening up an office in Denver that is focused specifically on support and care. As a result, these kinds of wait times should not continue going forward.
One of our team is looking into your case and should be responding shortly. We are always committed to getting better and appreciate you giving us the chance to prove that. Thanks and again, we've very sorry about that.
Channeling patio11 here, but CHARGE MORE! Or, more to the point, have some ways to price-discriminate. Maybe on # of employees; maybe on features; maybe integrations or SSO or whatever.
Obviously you're not (currently) targeting Big Enterprise, but even within your present target market there's got to be a difference in how much value you're delivering for different clients... price based on that!
Global Entry is for immigration/customs, not TSA security.
The trade-off is: they do a background check and take some biometrics, and in exchange you can skip the conversation with an immigration agent where they ask you where you're been, etc. - you just answer the usual customs-form questions at a kiosk.
It's actually a pretty reasonable trade-off, and speeds the process of going through Customs - which, unlike some of the TSA stuff, is in no way unique to the US (having gone through immigration/customs in 20+ countries, I can say with some experience that the US is far from the worst...)
"Software engineering estimates and plans often fail to live up to the reality that follows. It seems to be the only engineering discipline in which this is regularly the case."
Is it though? I live in Boston, home of the notorious* Big Dig[1]. While particularly egregious, it's far from the only large-scale civil engineering project that's gone off the rails. In fact, I'd argue that until fairly recently, many more public works projects shared the "surprise factor" of software projects. I'd recommend Caro's "The Power Broker"[2] for a fascinating history of NY-area public works (among other things - great book all around), including how much of that process was about adapting the plan to new things the builders were learning along the way ("oh, turns out that soil is completely different than we planned...")
That's not to say that there aren't particular features that make software engineering its own special snowflake - as there are meaningful differences between how civil, structural, mechanical, etc. engineers operate. But spend some time in another engineering organization and you'll find it's different, but not as different as you think it is.
(And FWIW, even civil engineers sometimes follow "agile" concepts - a company I once worked for was contracted to design a highway, and even after the construction started, engineers were "embedded" with the builders to make on-the-fly adjustments based on the environmental factors they discovered throughout the process... I wish I could find their project write-up, but it was a while ago and the company has long since been gobbled up by a bigger company).
* As a (subjective) kicker, I'd add that the Big Dig, over-time and over-budget as it was, was ultimately quite worth it... much like many software projects!
Yep, you're right... I'm forgetting that physical engineering also suffers from some of the same problems. The thing that it adds though is a level of rigour, and ability to reason about the project, that we're still struggling with somewhat in the software world. Believe me, in 20 years since I was taught it's not strict "engineering", I've yet to see that change much, other than in safety-critical and cleanroom projects.
Engineering is much more straightforward, you have the plans and know that you need X amount of parts and Y amount of labour. Software is more like research, where you don't even know if you can solve the problem acceptably, most of the time.
If you have the plans, it's manufacturing, not engineering.
The engineering in the design is in developing the prototypes and proving that theoretical concepts can be implemented practically. There is nothing straightforward about that, unless it is an incremental improvement to an existing implementation.
The engineering in manufacturing is about deriving ways to manufacture parts with greater yields and greater efficiency. In some cases, it is about developing manufacturing techniques that were hitherto impossible. Again, not much straightforward about this.
All of the above is rigorous, but that is not the same thing. This rigor can be applied to software development just as easily as any other product development, and when it is it becomes software engineering.
I feel it's the lack of hard laws that kill software. Unless it's a very constrained project, where limits drive your design, you'll have freedom to think about things and then it shifts into ontologies, people trying to find 'tiny theories' to express their problem in the best way. Each layer adds variability and we end up in hard to bridge technology silos.
Rough ballpark: 300 million combos - let's say you buy 6000 tickets/hour (which I think is actually optimistic probably by a full order of magnitude), for 25 hours a day (assume shifts and magic days), you're still looking at 2,000 person-days.