[FRIAM] I am accepting wagers

[Tom Johnson]

Welcome to FRIAM, pal.
Tom

On Sun, Mar 14, 2021, 9:46 PM Chris Feola <chris at 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 <profwest at fastmail.fm>
> *Sent: *Sunday, March 14, 2021 9:45 AM
> *To: *friam at 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/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://redfish.com/pipermail/friam_redfish.com/attachments/20210315/e9a1cd0c/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: A95E8161989043A9A347615067102ABE.png
Type: image/png
Size: 154 bytes
Desc: not available
URL: <http://redfish.com/pipermail/friam_redfish.com/attachments/20210315/e9a1cd0c/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: A95E8161989043A9A347615067102ABE.png
Type: image/png
Size: 154 bytes
Desc: not available
URL: <http://redfish.com/pipermail/friam_redfish.com/attachments/20210315/e9a1cd0c/attachment-0001.png>