Thanks for bringing some more reality into this discussion. I’ve never been a CIO, but having been a software engineer in the real world for 25 years, it triggers something in me when someone dismissively claims that a small group of developers / hackers could turn out software for a gargantuan user base and thousands of disparate clinics in a weekend. I have no patience for such hyperbole.
On Sun, Mar 14, 2021 at 10:46 PM Chris Feola <ch...@feola.com> wrote: > “Of course they did not have access to real databases, nor did they have > to solve problems of data reconciliation among those disparate databases. > This kind of infrastructure, as was pointed out, would have added > significant time for them to complete a 'full function' app.” > > > > This reminds me of the old Monty Python sketch How To Do It-How To Play > The Flute: Well, you blow in one end and move your fingers up and down so > the right notes come out. ANYONE could have built the site in a week or two > if they didn’t have to connect it to the legacy databases. Features are > easy, and preexisting ones– how long have companies been selling insurance > online? – are stupid easy. > > > > Data is hard. Integration is really, really hard. > > > > Here’s just one problem: Take a look at, say, your Amazon account. How > many shipping and billing addresses are there? How many are duplicates-say, > where the shipping and billing address are the same? > > > > Now, the user changes a zip code. Do you update any of the other > addresses? If so, which ones? > > > > That ONE problem is called Master Data Management, and companies spent > $11.3 BILLION trying to solve it in 2020. > > > > Sorry for the rant. Just an old CIO venting. > > > > Cjf > > > > Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for > Windows 10 > > > > *From: *Prof David West <profw...@fastmail.fm> > *Sent: *Sunday, March 14, 2021 9:45 AM > *To: *friam@redfish.com > *Subject: *Re: [FRIAM] I am accepting wagers > > > > At the peak of the healthcare.gov fiasco, *Sixty Minutes,* did a segment > on a small company in San Francisco — five people — built site with all the > capabilities, including calculating subsidies (supposedly the most > difficult feature), of the official site. It took them a weekend > (supposedly) — but definitely some very short time span as they did not > begin the effort until the bad publicity became prominent and the episode > aired less than two weeks after the initial debut/failure of the official > site. > > > > Of course they did not have access to real databases, nor did they have to > solve problems of data reconciliation among those disparate databases. This > kind of infrastructure, as was pointed out, would have added significant > time for them to complete a 'full function' app. And, of course, because > they were not the government nor the government approved contractor they > would never have been allowed access. > > > > davew > > > > > > On Sat, Mar 13, 2021, at 7:59 PM, jon zingale wrote: > > """ > > *I can see a lot more work needed that will never be seen from the > public’s side of the system. The 50,000 sites will not be constant. Some > new ones will come, and some will go. Hospitals, public health departments, > independent as well as chain pharmacies have to feed information into the > system. How do they pass that information? How do they prove they are not a > hacker and have the authority to change hours, capacity, availability of > vaccine, location, etc. Are there mechanisms for weeding out defunct and > out-of-date vaccination sites? The problems getting up-to-date and accurate > numbers for COVID tests, deaths, ICU usage, etc., demonstrate this is not > trivial. * > > """ > > Not trivial, but also tinker toys. Industry-level authentication of > RESTful services is a pattern that many of us on this list ought to be able > to implement while skimming Instagram or playing online go. A small team of > Friammers and/or a few interested parties could have something up in a > month that would be considerably better than healthcare.gov or the New > Mexico Unemployment app. Some on this list are pretty bright and could > write or implement formal verification software > <https://galois.com/research-development/software-correctness/> for > proving the correctness of the code. > > It is so easy to point to software that doesn't do as advertised that it > is easy to miss out on what the present state of the art actually is. The > anecdotal cases are click-bait. But hey, I have spilled enough ink on this > subject already. Yes, we *can* have nice things. > > Sent from the Friam mailing list archive > <http://friam.471366.n2.nabble.com/> at Nabble.com. > > > > - .... . -..-. . -. -.. -..-. .. ... -..-. .... . .-. . > > FRIAM Applied Complexity Group listserv > > Zoom Fridays 9:30a-12p Mtn GMT-6 bit.ly/virtualfriam > > un/subscribe http://redfish.com/mailman/listinfo/friam_redfish.com > > FRIAM-COMIC http://friam-comic.blogspot.com/ > > archives: http://friam.471366.n2.nabble.com/ > > > > > > > - .... . -..-. . -. -.. -..-. .. ... -..-. .... . .-. . > FRIAM Applied Complexity Group listserv > Zoom Fridays 9:30a-12p Mtn GMT-6 bit.ly/virtualfriam > un/subscribe http://redfish.com/mailman/listinfo/friam_redfish.com > FRIAM-COMIC http://friam-comic.blogspot.com/ > archives: http://friam.471366.n2.nabble.com/ >
- .... . -..-. . -. -.. -..-. .. ... -..-. .... . .-. . FRIAM Applied Complexity Group listserv Zoom Fridays 9:30a-12p Mtn GMT-6 bit.ly/virtualfriam un/subscribe http://redfish.com/mailman/listinfo/friam_redfish.com FRIAM-COMIC http://friam-comic.blogspot.com/ archives: http://friam.471366.n2.nabble.com/