White House Claims ‘Dramatic Progress’ on Health Site Administration Officials Acknowledged ‘More Work to Be Done’
White House Claims ‘Dramatic Progress’ on Health Site – WSJ.com
Crack software experts are working on a way to retroactively make Obama’s repeated lies about Obamacare disappear.
The Obongo misadministration claiming “dramatic progress” on his Signature FAIL is akin to them claiming that a putrefying horse carcass exploding in the street is a “dramatic improvement” to the neighborhood.
The “fix” was was never more than a gambit invoked in late October to get everyone to STFU about the website. People should not have shut up.
FINALLY! The OBAMACARE website is ready for your inspection. Click here http://home.roadrunner.com/~pjrpole/ACA.html to check it out.
Even if you don’t need insurance and you’re just curious, go to the
website and click on the green Apply Now! button to see how it works.
😆
From a letter making the rounds:
“The 600 million dollar website that doesn’t work was made by a company with a lousy track record and a top executive who’s a pal of the First Lady, Toni Townes-Whitley, Princeton class of ’85, is senior vice president atCGI Federal, which earned the no-bid contract to build the $600 million Obama care enrollment website at Healthcare.gov. George Schindler, the president of the Canadian-based CGI Group, CGI Federal’s parent company, became an Obama 2012 campaign donor after his company gained the Obama care website contract…….Three other companies submitted bids for Obama care, but CGI s bid was the only one considered.”
There are a dozen reasons for Boner to have appointed a special prosecutor so far, and he hasn’t done it. They are all knee deep in this filth together.
Plouffe: Obamacare “Will Work Really Well” By 2017
http://www.realclearpolitics.com/video/2013/12/01/plouffe_obamacare_will_work_really_well_by_2017.html
I have heard estimates of 5 to 500 million lines of code in the website. Commercial quality code standard is one bug per 1000 lines of code. Assuming the estimates encompass what it actually is, there are an estimated 5000 to 500000 bugs in the website. Considering the the website was managed by government types, that estimate is likely way too low.
It is almost impossible to fix multiple bugs in large complex software without adding still more bugs. The most that can be done is give a superficial appearance that it is working. However, even that would be too generous, it simply has behavior that sometimes is what is expected, other times what is needed, but most times it does nothing useful and even harmful.
The bottom line is that the website cannot be fixed to the level of any rational meaning of the term.
Full disclosure: I have been developing complex scientific, engineering, data acquisition, process control, and image processing software since the mid 1960’s. A good bit of that software was life critical. Hitting a bug could and often would result in one or even many people dieing. During that time my standard was less that one bug discovered by the user in 10000 lines of delivered code. The key to success was to deliver the least amount of code that could accomplish the required task after design it carefully, building it in small chunks, and testing as the modules are built and integrated. To the best of my knowledge, my software has not killed anyone.
Do you speak RSX-11M?
You ask about computer ancient history. During the 1970s, I used RSX 11 to program in Fortran and PDP 11 assembly language quite extensively. The software was developed for use on commercial electron micro probes, ion micro probes, mass spectrometers, and optical emission spectrometers. My software was used to analyze metal ores, moon rocks, diamond matrix, steel, lead, zinc, copper, aluminum, cement, et.al.
Dittos. I ran a manufacturing plant with PDP-11s in the late 70s. I F4P.
A little more history for the pot from a hired gun. In my brush with the spectroscopy industry in the late 70s (Baird Atomic) was still hung up on the PDP-8. Bleeding edge was RT11 on the LSI-11-03. RSX was way too profligate for lean and mean instrumentation.
Gary,
As they say: “Ah those were the good old days!” Well, not quite that good but it was a living.
I also programmed the HP1000 paper tape OS for the optical emission spectrometers.
BTW: I was working for Applied Research at the time. We were competitors.
DEC Macro-11 was a wonderful assembly language to code in. Recently, I’ve had to reverse Intel x64 object code. What a nightmare!
Tom,
You found x64 assembly that good? I have programed more computer architectures in assembly than I care to recall. The PDP11, 6502, and 68000 series are among the best and easiest to program in assembler. The Intel x86/x64 chips I found to be among the worst and not even as good as a nightmare. I learned how to do it but I refuse to program them in assembler any more. I use a subset of ANSI C to achieve similar results with much less effort. I can accomplish anything I need to accomplish in ANSI C with performance, compactness, ease, stability, and portability. The later developed languages can’t even come close. I don’t even bother with them unless there is no other way to proceed.
I loved the Motorola 68000 series assembler. Still have my ’92 model Amiga A1200. X86 assembler is such a bitch it’s almost an insult to any programmer.
Agree. gcc -ansi -Wall is my preference and, if you want to have some fun, -pedantic.
Lionell, Tom
More good old days 🙂
I worked on HP2100 based instrumentation for Trident. Two index registers, two accumulators, no stack, no call linkage. You used a macro package for assembly language or lost your sanity. Loadable control store made it a wicked Fortran box since all you were doing was sequencing microcode. Our box had three full IEEE buses, no idea what was on them anymore.
Or how about the Data General boxes? Assembly language like microcode – each instruction had alu and branch qualifiers. It was the all time winner for writing the shortest integer multiply back in the days when that was the first thing you needed to do when moving to a new machine. Chronic overheating problems on the Nova, the Eclipse was hot in other ways.
My first pdp experience was a doing Fortran on a Dec-Tape based pdp 11-05. A few hundred line compile took an hour and gave you enough time to sweep up all the oxide that ended up on the floor. Excellent motivation for learning Macro-11.
If your interested in funky gcc, check out my haveged FOSS project – it’s as close as I get to the iron these days.
Software experts on crack are working on a way to retroactively make Obama’s repeated lies about Obamacare disappear.
Fixed!
Wait just one minute now. The software guys they brought in to fix (i.e., completely rewrite) the code are most likely highly capable software developers who are not culpable in any way for the CGI disaster. They have been assigned an enormous task to accomplish in a short period of time and are probably working their asses off to get the job done. If you have never been on a death march software effort you have no idea what these guys are going through now.
BTW, Lionell Griffith clearly knows what he’s talking about and almost certainly does know what the software guys are going through. Any additional comments, Lionell?
Been there, done that, never want to do it again! It is the path to insanity.
I worked as a contractor for four years developing real time 3d Graphics and data analysis software for NASA. The situation behind the website was likely similar.
1. Massive but incoherent, incomplete, self contradictory, over determined specifications, and usually many not identifiable nor identified requirements.
2. Tools and development process to be used are specified/mandated in detail by people having no knowledge of the task, the problems to be solved, how to solve problems, nor how to develop software.
3. Budgets and schedules are designed on the principle that the software will be developed exactly as specified without error and without the time and resources necessary to understand the problem to be solved and without the necessary time and effort being expended in testing. The actual developers are never consulted or at best ignored in this step.
4. Frequent meetings to discuss problems in which the relevant problems are not to be mentioned much less discussed and resolved. Attendance is mandatory and nothing much is actually accomplished except that the managers can report that a meeting was held.
5. The bulk of the effort on the part of the people doing the actual work will be spent in meetings, writing progress reports, and trying the convince the program managers that the specified solution does not address the real problems and that the tools and process they are required to use hinder progress more than they help.
6. The project managers report the project is on scheduled and on budget for 80% of the schedule.
7. To make the system even close to functional after the first 80% of the schedule and budget is expended it will take at least that much more schedule and budget if not two or three times more.
8. Then things start going really bad.
Such projects always involve death march development that follows the pattern that fails and burns out the development team. The system that is delivered is never what was specified, does not do what is required, and is simply decreed that it is done because everyone is exhausted by the effort. Then the self same approach is used on the next mega project. Actual useful results are an unintended side effect.
Meanwhile, if a proper front end investigation were done to facilitate really understanding the problem and the tools and development process consistent with solving the now understood problem were allowed, 80% of the system would have been working within 10% of the originally proposed schedule, budget, and resources. The remaining 20% will have been discovered to be not necessary. However, since that approach would have worked, it was not permitted to be considered.
The government never does any thing that really works. If they did, they could not justify expanding the schedules, budgets, and staff. This requires failure. Hence a government project is a success only when it fails. See the Challenger incident as a case in point. NASA was successful. Budgets were cut. The Challenger was destroyed. NASA was given billions to build a new one. NASA learned the lesson well.
PS: I no longer accept projects based upon a large development team and a predetermined specification of how things will be done. They always fail. If they succeed, it is because there is a very small core team actually doing the work. The bulk of the project team are simply dead weight as best and are usually an impediment to getting anything done. See The Mythical Man Month (ca 1960) about the development of the IBM 360 OS for instructive detail.
We had a saying: “We’ve been doing so much, with so little, for so long, we are now fully capable of doing anything with nothing.”
healthcare.gov is what you get when you spend $95,000,000 on a $500,000 website.
It appears the CGI base system was a bad choice to start with. You cannot turn a bad choice into a good choice via mass modifications. Kluge. Starting from scratch would be the best approach. HOWEVER, when you have government involved with business, they will make POLITICAL decisions, not business decisions. They will not start over, or just go away, because of the politics. The overarching point of all this is that government should stay the heck away from health care. People will die, just so they can make some constituency happy.
An overworked but very true cliche in engineering: “There is never time or money to do it right, but always time and money to do it over.”
Tom,
This even though by using an appropriate process and matching tools, the task could be accomplished in much less time and budget. However, this requires that mangers understand their job has nothing to do with making decisions. It is only to find the right people to do the work, making sure the right objective is identified, and providing adequate facilities, tools, and resources to get the work done. The only real decision that a manager has is Go or No Go. There is no other decision he can make that will aid progress or avoid harm.
Unfortunately, I know of only a very few managers with this understanding. Almost to a man, they believe their job is to make decisions and that being really informed and skilled is an impediment to making them. They think the most important thing is to make the decisions. It is for the mere mortal worker to work out the details without objection, discussion, or understanding. In a very real sense, this type of manager has no constructive job that they are capable of doing.
It is interesting to note that I have repeatedly been identified as “Not a good team player” by this type of manager. Largely because I clearly point out to them the stupidity of their decisions, the disastrous consequences of attempting to make them happen, and actually have demonstrated how bad the decision is. They don’t like being shown they are idiots. I don’t give a damn that they don’t like it. My goal is to make things that really work and not to make some maximally stupid manager look good or feel good.
Most of the time, I simply allow the system to do its thing and stay out of the way. Then when it hits the fan and the nails are being driven into the managers hands an feet, I tell and show them what I can do for them. Often then I am allowed to do my thing and it works! Sometimes I have to walk away. However, what I will no longer attempt is to try to make the system work in spite of itself. The effort is not worth the result.
Impressive posts. If I submitted four paragraph responses, I’d make at least four logical and/or factual errors.
I will add that many software managers I’ve known were among the least talented engineers in the organization and were often somewhat defensive due to their obvious lack of talent. They made poor decisions and were not inclined follow the advice of the software guys they managed. The larger and more bureaucratic the company (e.g., GE) the greater the problem, perhaps because the managers in those companies were usually ladder-climbers.
“White House Claims ‘Dramatic Progress’ on Health Site”
Put up a Mission Accomplished banner on the deck of HHS.
If Obummer DIDN’T use 1000 typing monkeys to code the site, maybe they would have done a better job.
At least 1000 monkeys couldn’t have done much worse and would have done it for bananas rather than an obscene salary. Unfortunately, even though the government’s real goal is failure, to fail on the cheap is totally unacceptable.