Posted on 10/21/2013 6:55:49 AM PDT by Sub-Driver
HealthCare.Gov Needs Five Million Code Lines Rewritten By Andrew Johnson October 21, 2013 9:13 AM Comments 42
Obamacare’s online exchanges have been riddled with problems since they came online three weeks ago, and those issues may continue for at least the next few weeks. Contractors said fixing the problems by the November 1 deadline set by the administration would be “unrealistic,” according to the New York Times.
From the sluggish websites to garbled enrollment information, the flaws require the extensive rewriting of code: “One specialist said that as many as five million lines of software code may need to be rewritten before the Web site runs properly,” the Times reports — that’s out of a total of approximately 500 million lines of code, according to another expert.
Others experts warned that some of the website’s problem are yet to come. One technical specialist involved in the repair effort said, “The account creation and registration problems are masking the problems that will happen later.”
From an experienced coder:
Even small projects with just five to ten screens take months to research, plan, write, debug, debug, debug, roll out, and debug, debug, debug.
There is no hope for Obamacare code. It will NEVER be fixed.
My guess is that the system was designed by Bureaucrats. They are probably making calls to other systems like the IRS to obtain/verify data.
No, it was not blown out of proportion, at least for the industry I work in, healthcare.
We had to test and evaluate the hundreds or thousands of pieces of software AND equipment that could have potentially caused problems, and we did find them.
Any time there is a problem with a date field in a charge file where an insurer is involved is serious. You don’t get paid, and you go broke. And they are looking for an excuse not to pay the claims, sending a completely wrong date is like handing money to them on a platter.
And every system had to be tested, from systems that powered operating room equipment to imaging equipment. And they had to be tested thoroughly. If you happen to be on the operating table or waiting for a crital image to come over from radiology for your collapsed lung and it won’t send properly because some snippet of code is looking to see if the date of the images meets some kind of valid date criteria.
Maybe it was overblown for people working in the utilities, aviation or something like that, but if the things I saw in medicine were any indication, there were problems in other fields as well.
They ALL had to be tested and correcte, which was a huge effort. I was quite proud of my institution’s actions prior to Y2K. They took it very seriously, and we did find problems.
Nothing personal against you, but to say it was blown out of proportion is not in any way correct.
There's your problem right there.
And since it will be viewed as a government "jobs" program, every criteria except competence at coding or project management expertise will be used to hire candidates to fix it.
There will be a lot of people working who really, REALLY need a job, and their sex/race/ethnicity/social status/income level will count 90% towards hiring.
Just watch.
But can you write a single script that when run will correct their 5 million mistakes?
Hahah, LAZ will probably say no, but you can bet that there are people out there who will try to jump on the gravy train who WILL say they have a shortcut.
Granted, there was some unwarranted hysteria but there were also a lot of systems that would have stopped working correctly. There were a lot of programmers working in the trenches to get systems modified.
IIRC.
Unfixable. This thing may never work.
I wonder if it ever was meant to work.
That said, FR runs on PHP, but it is the brainchild of one person (more manageable), much smaller scope (more manageable), and evolved over 12 years (more manageable) — and it still has some bugs.
I thought FR was implemented [mostly] in Perl… though I can't remember where I read that.
That truly is a great point, Laz.
This "system" isn't rocket science. They shouldn't be writing and incorporating complex algorithms, and they shouldn't be re-inventing the wheel...at it's heart, such a system should be validating and verifying data, and moving information around. There are plenty of software libraries out there that can do much of this work with a few calls. This should include security, as well.
You’re right, I was working as an applications developer for a large health insurer at the time. I should have said that the more spectacular fears were blown out of proportion. I am familiar with the specialized equipment problems but even a lot of those were overstated. The real story was that all of those real potential problems were being taken care of. The planes falling out of the sky and lights going out were possible in some instances but the press created a panic that the end of the world was here when in reality most of those problems were addressed, sometimes a year or two prior to Y2K You, I, and a lot of our colleagues worked long hours in addition to our regular work to make sure that on 1 Jan 2000 there were no glitches. There were not.
This ACA fiasco is another matter. There is no concievable way that 5 MLOC in a complex system like this is going to be fixed in two weeks and I doubt even two years. It might be faster if they just throw out everything, do some real requirements gathering and analysis, and build a new system from scratch. Then again, I want to see it fail and miserably because it supports an unconstitutional and dicatatorial oppression of American citizens.
Finding and fixing date code is one thing -- you know exactly what to look for, and exactly how to fix it.
Finding faulty logic in a program that doesn't work, is another thing entirely.
You’re right, LOC has never been a good metric for much other than to give a crude concept of the size of the system. It does not indicate the complexities and how the various structures fit together. LOC was a PM/management indicator that managers liked. I never knew any developer who gave it any credence.
Truth is, they really don't know - they need TIME to investigate. Re-writing code to integrate into existing code requires analysis of ALL of the existing code - in order to see WHAT needs to be re-written and HOW it can be re-written so that it can be seemlessly merged with the existing code. Its like forging the Mona Lisa - you have to study the brush strokes BEFORE you start the forgery ...
And, SOMETIMES, it can't. You just have to scrap the original code and start all over.
I guess your view of blown out of proportion depends on what industry you were in. I worked for the FAA than and there were resident programmers and systems people there on staff. They caught the problems in the software used nationally at headquarters and all the local software was checked. Planes falling out of the sky was overblown. The failure of power and communications was overblown. We ran on generator power just go be sure. It was much to do for a non event. Guess over blown depends on ones point of view.
I still have Y2K beans and rice.
That the ACA site was written in PHP is utterly mind-boggling.
You can find and fix a lot of “errors” quickly but following the cascading effect of that error throughout the system can be a long term nightmare. Fix one problem in a complex system can break a hundred other processes that are interconnected.
In the old COBOL days we spent months tracking and fixing a main program and 40 or 50 other programs and their files that used output from the main process. The problem was one missing period at the end of a line of code but it required temp fixes to 3-dozen other applications that used the data output from that one program as well as rebuilding the financials files that came from all of those programs.
Agreed. I managed two different testing teams with two different companies. There would have been health care and utility disasters without the remediation.
I set up a competition with the programmers. If the testing team found a problem they had missed, they bought us drinks. If we failed to test a segment, we bought them drinks. All in all we had a good time and finished well in advance of our target dates.
I think the media ALWAYS overhypes anything they think will sell. Look at what they did with the government “slimdown” and with George Zimmerman and a thousand other things.
Nope. I am a PM, engineer, and programmer.
They need to fire the original PM team and replace with STRONG PMs, elicit a set of User Requirements from the government and lock them down, produce a set of deliverables and a timeline, write code, Alpha Test the modules [done by programmers] as they are created, and then Beta Test modules with real-world users.
As bugs are found, and they will be, rinse and repeat until no more bugs can be found. This necessarily adds time to the project and timelines need to be pushed out.
Once the individual modules seem to be stable, the whole system needs to be integrated together and Alpha Tested [by programmers], and then Beta Tested by real-world users. Again, any bugs [and there are sure to be at least some] will necessitate rinse and repeat, as above.
FINALLY, any deviation in user requirements along the way MAY necessitate starting back at square 1 ...
Disclaimer: Opinions posted on Free Republic are those of the individual posters and do not necessarily represent the opinion of Free Republic or its management. All materials posted herein are protected by copyright law and the exemption for fair use of copyrighted works.