Replies

Excuse me, but...

I am a Web/Software Developer/ System Admin who works primarily in PHP (also JS, JQuery, Linux - LAMP stack for short). Some of the biggest web systems out there are PHP based. Facebook, Yahoo, Amazon just to name a few.

You can see a full list here. Also, many of the initial errors I saw were java errors (tomcat server stack errors). In short, PHP is not the problem here.

As a programmer with almost 14 years under my belt, let me also state that I've worked on some pretty busy web systems (including ones now that help deliver news and commentary to many of you every day), and none of them had 5 million lines of code. That sounds like either hype, some contractor trying to hike up their fees, or complete spaghetti code.

But let's look at the bigger technical web picture here...

From a webdev standpoint, The HealthCare.gov website's functions should be as follows:

Accept input data via forms
Write input data to a database
Read input data to display on screen, reporting or document creation
calculate insurance costs based in data input

Sorry folks, but all that is Web Development 101, and even other government websites that do the same thing seem to work without a problem. I estimate the HealthCare.gov site could have been written in no more than 5000-6000 lines of code using existing open-source frameworks (and that's being generous).

From the reports I have read and the errors reports many of my colleagues have passed around, no load testing, unit testing, and very little Q/A was done with the site itself. Large, corporate web sites were build better for a fraction of the costs, and no errors.

In fact, the entire roll out of HealthCare.gov has been flawed. Let me put this in non-geek terms so everyone can understand:

Say Black Friday is coming. Right now, the big-box corps (Sears, Wal-Mart, Target, etc) are working on their promotions - a full rollout to start promoting BEFORE Thanksgiving, right? We're talking TV, radio, print AND web - all to start in November. Did you see any of this with failed HealthCare.gov?

No, you only saw Oct 1 get here, and media people could not even complete a form. Again, the whole rollout was flawed from the beginning, and if the Tea-Party fight forced the White House to push the site out before it's time - which many of us suspect, then Ted Cruz et al did their job - perhaps without even knowing it. Someone high up HAD to have seen these errors, and said "Launch it anyway"

I could go on, but I need to run into yet another scrum meeting, with other web developers.

It's funny. I'm wondering if Cruz had some inside info on the problems of the website.

He and the House Repubs demanded that ObamaCare be postponed for a year. So naturally Obama COULD NOT allow Obamacare to be postponed for even a day, since that would mean that Republicans had "won". So it rolled out on schedule, to be a complete disaster, because the boy-child could not give even the appearance of the Repubs winning at anything.

This suggests a strategy: whatever you want done, issue a demand to Obama to do the opposite.

From a webdev standpoint, The HealthCare.gov website's functions should be as follows:

Accept input data via forms
Write input data to a database
Read input data to display on screen, reporting or document creation
calculate insurance costs based in data input

Conceptually, yes; implementation wise, no… precisely because data needs to be validated between #1 and #2.
Here's why: Healthcare data.

Consider something as simple as a social security number; off the top of my head:

JavaScript dependence/disabling: nothing in this site should require javascript, as its use is [essentially] mandated by the government and therefore must comply with ADA and accessibility standards, including text-only browsers.
Because of #1 you cannot count on client-side validation, therefore *all* validation needs to be done in the client-side code.
Because of #2, a SSN may come in in several forms: dashes, no-dashes, spaces, etc. (You can do this w/ regex, though regex solutions are typically too brittle for complex [i.e. non-regular] data.)
Because of #3, combined with the general inability to declare types, it is now incumbent on the programmer to do [at least some] flow analysis when making any changes. (i.e. ensure all inputs to the function are validated.)
(Mitigated if using OOP; however, OOP is rather bolted-on in PHP, there are many tasks for which OOP is an unnatural solution, and there can be memory concerns on some systems [admittedly may or may not be an issue in newer PHP versions].)
Now we need to add it to the DB&hallip; wait, did you know that a SSN isn't unique? (Did you set up the DB assuming they were? Is your code assuming they are?)

Validation though is the 'core', if you will, of verifiable S/W — which you want for critical medical systems. (I'd argue for even non-critical medical systems.) The above is actually very small, and as such there are things you don't even need to really account for, like poor Bobby Tables, because the data is just a numeric-string — once you get into validation PHP quickly becomes terrible, because of the loose take on types.

The above validation-insurance for SSN can be expressed in Ada as this:

Type User_ID is new Positive; -- ID for a record; cannot be confused w/ a integer-count. Subtype Digit is Character range '0'..'9'; -- The following is a string, of length 9, that has ONLY digits. Subtype Social_Security_Number is String(1..9) with Dynamic_Predicate => (for all C of Social_Security_Number => C in Digit); -- The following function cannot have an invalid invalid SSN parameter. Function Save( SSN : Social_Security_Number ) return User_ID;

I can make the above guarantees because they are ensured by the language; without ever looking at the body of Save I can tell you it cannot be called w/ an invalid SSN and that it will return a positive integer. Moreover, the guarantees can be used to prove the program's correctness w/o relying on any flow analysis. (Flow analysis might be needed on the internals of functions, but not on the interfaces; thereby allowing for far better modularization and subsystems.)

Sorry folks, but all that is Web Development 101, and even other government websites that do the same thing seem to work without a problem. I estimate the HealthCare.gov site could have been written in no more than 5000-6000 lines of code using existing open-source frameworks (and that's being generous).

Perhaps, but how confident are you that you can say the data in such a DB is valid? [IIRC, there's stuff in ACA about mandating electronic medical records.] Moreover, how much would you want to be forced, under penalty of law, to use a site that isn't actually validated? Howabout submitting sensitive medical data, upon which your life may one day depend (drug allergies, perhaps)?

I don't like that idea.