News Cover Oregon goes to Healthcare.gov

[SteamKing]

But in defense of these people, the public has unrealistic expectations on software. These kinds of problems are common, and usually companies allot more time or even cancel the project. Politically speaking, many people were looking for an excuse to snipe obama on health care. So extending the time in the SRS became politically impossible.

The ACA did not come about in response to a great clamor by the public. It was something passed on a purely partisan vote in both houses of congress due to some questionable parliamentary maneuvering by the Democrats, which forms the basis of at least one federal lawsuit still wending its way through the courts.

The whole program was designed first and foremost to be a one-stop-shop to purchase health insurance, as mandated by the law. The whole process of enrolling at healthcare.gov was to avoid the hassle to doing the enrollment by filling out stacks of paper forms.

When a person sat down to enroll, he was supposed to be able to examine the types of coverage available and make a selection based on health coverage needs. In order to price these plans, the prospective customer had to provide information about his family, where he lived, whether he was already covered, etc. Because of the way premium subsidies were structured, based on the income of the prospective customer, the system also needed to know something about that to determine eligibility and then the amount of the subsidy available.

Government being government, the plan administrators wanted to verify all these personal and financial details in real-time while the customer was enrolling; no call backs, or we'll see you later type delays. This meant that the healthcare.gov website needed to interface with other federal databases, which were not designed to be accessed by people at large.

Whatever the reasons, the contractors chosen by the feds to develop the website for healthcare.gov reportedly did not have a stellar resume of performance. Their last big contract was developing a firearms registry for the Canadian government, which contract also went over budget and slipped past its delivery date.

It's not that the public at large has unrealistic expectations about what software can or cannot do, because the public was not in charge of this mess. It's the politicians and other bureaucrats who cooked up this 'stinkburger' (to use Obama's phrase) who had unrealistic expectations but persisted in forging ahead nevertheless against some pretty well-reasoned advice until the disaster was made real when the website premiered.

But for one fateful encounter with an iceberg, the TITANIC might have sailed happily for many years with no problems. It's not like there was a crowd of people at the dock when the ship sailed warning that she was doomed to fail so spectacularly and so suddenly.

And it's not like this is the first time the US government has run into problems developing a large software system. To cite two examples, the FAA has spent many years trying to upgrade and modernize its air-traffic control system:

http://gcn.com/articles/2013/07/22/faa-next-generation-air-transportation-system.aspx

An inspector general's report has concluded that the new system will take 10 years longer to complete and cost billions more than anticipated.

A similar report concluded that the Social Security Administration was relying on woefully obsolete computers and software to manage the data it collects on wages earned by US workers and to work through the backlogs in processing disability claims and providing administrative hearings to resolve disputes:

http://otrans.3cdn.net/134afc3b9a10670ba2_vgm6y9zu5.pdf

I have little sympathy for Obama & Co. All during the protracted development and roll-out of healthcare.gov, the party line was that if you were satisfied with your insurance and your doctor, you could continue on as before the ACA was passed. When the regulatory structure was being built around the law, it became clear that the president's solemn promises were no longer 'operative', to coin a phrase used about a previous occupant of his office, everyone continued as if these promises had not been made.

 

[SixNein]

Whatever the reasons, the contractors chosen by the feds to develop the website for healthcare.gov reportedly did not have a stellar resume of performance. Their last big contract was developing a firearms registry for the Canadian government, which contract also went over budget and slipped past its delivery date.

These things happen in complicated projects. And it's not limited to software. As I stated above, many hard engineering and scientific projects go over budget and over time.

It's not that the public at large has unrealistic expectations about what software can or cannot do, because the public was not in charge of this mess. It's the politicians and other bureaucrats who cooked up this 'stinkburger' (to use Obama's phrase) who had unrealistic expectations but persisted in forging ahead nevertheless against some pretty well-reasoned advice until the disaster was made real when the website premiered.

Like I say, we should use this logic for science budgets. And you know I could cite many examples here.

For example, the Large Hadron Collider was a disaster. In addition, a great many projects by NASA has been a complete disaster. Here is a list of a few of them:
http://www.nbcnews.com/id/29514257/...t/big-nasa-projects-over-budget/#.U5j8rvldWHM

Fair is fair right?

I have little sympathy for Obama & Co. All during the protracted development and roll-out of healthcare.gov, the party line was that if you were satisfied with your insurance and your doctor, you could continue on as before the ACA was passed. When the regulatory structure was being built around the law, it became clear that the president's solemn promises were no longer 'operative', to coin a phrase used about a previous occupant of his office, everyone continued as if these promises had not been made.

Maybe people should read the bills.

 

[nsaspook]

You're right.

We should use the same kind of logic to cancel the NASA budget, and also cancel most science funding by government. These programs are full of people who frequently go over budget and over time. They are not professional enough because they are working for the government.

Government is just too incompetent for those types of things.

Science projects are pushing the frontiers of what we can do past the boundaries of simple engineering with current technology and is exactly the type of projects the 'Government' should invest our tax dollars in. If NASA was in the business of making failed complex health-care systems instead of developing and engineering the space exploration knowledge base of the future I would agree to your logic but you have a straw-man argument that's completely off track. I don't see much that's new and novel about the 'Cover Oregon' software system specifications and requirements that you could possible compare to a complex physics based scientific project like the LHC that can recreate conditions as close to the birth of the universe as humanly possible with todays technology.

 

[SixNein]

Science projects are pushing the frontiers of what we can do past the boundaries of simple engineering with current technology and is exactly the type of projects the 'Government' should invest our tax dollars in. If NASA was in the business of making failed complex health-care systems instead of developing and engineering the space exploration knowledge base of the future I would agree to your logic but you have a straw-man argument that's completely off track. I don't see much that's new and novel about the 'Cover Oregon' software system specifications and requirements that you could possible compare to a complex physics based scientific project like the LHC that can recreate conditions as close to the birth of the universe as humanly possible with todays technology.

Software engineers are also pushing the frontiers. In fact, a substantial portion of the success of LHC is due to software engineering. The same can be said of many of NASA's projects. Building health care systems is also a worthy goal. And these systems are very complex, and they too will run into budget and time issues. These issues just comes along with complex systems. Health care system of this kind might not seem complex in many peoples mind, but those people have probably never had to interface with lots of different systems while doing real time calculations so that someone can see how much he or she pays. And all of this is outside of all of the regulation requirements and security concerns in a high traffic environment.

The whole point I'm trying to make is the double standard used here. People are making arguments similar to something like: I can build a telescope in my basement, so why is the James Webb telescope over budget and time? It's disingenuous. We don't do that to scientists or engineers, and they should show the same respect.

 

[nsaspook]

Software engineers are also pushing the frontiers. In fact, a substantial portion of the success of LHC is due to software engineering.

The problem I see is the 'Dark Side' of software engineering with some failed IT projects like Cover Oregon. The problem is called lying. It's knowing that deadlines and milestones can't be met in the beginning and 'lying' about it. People don't like to hear the L-word but it's often the root of the failures we see in large software (and hardware) systems. It's just too damn easy to create mythical front-end demos that dazzle when the people who will actually construct the system know it's all a big lie when they write the estimated project costs, schedules or status reports. I'm not talking about 'hype', just flat out lying about the true scope and complexity to get the ball rolling with a 'we'll fix it later' software management system.

 

[SixNein]

The problem I see is the 'Dark Side' of software engineering with some failed IT projects like Cover Oregon. The problem is called lying. It's knowing that deadlines and milestones can't be met in the beginning and 'lying' about it. People don't like to hear the L-word but it's often the root of the failures we see in large software (and hardware) systems. It's just too damn easy to create mythical front-end demos that dazzle when the people who will actually construct the system know it's all a big lie when they write the estimated project costs, schedules or status reports. I'm not talking about 'hype', just flat out lying about the true scope and complexity to get the ball rolling with a 'we'll fix it later' software management system.

The complexity of many software projects are beyond a single human's ability to fully understand; as a result, cost estimation is extremely difficult. Basically, cost estimation is a educated guess based on prior history and other metrics associated with requirements.

Prototypes are used by software engineers in order to test user requirements. Many layman make incorrect assumptions about prototypes because people associate interfaces with completed software. So sometimes people think the project is almost ready even though it is in early development.

 

[DavidSnider]

Something I don't understand: If the federal government has paid to create software for a health care marketplace website why can't the states reuse 90% of the same code? Doesn't code written for the federal government belong to the taxpayers?

 

[SixNein]

Something I don't understand: If the federal government has paid to create software for a health care marketplace website why can't the states reuse 90% of the same code? Doesn't code written for the federal government belong to the taxpayers?

A part of this problem is due to the enormous strength of Intellectual Property. Any time someone creates software and publishes it, he or she is walking through a land mine field. I would imagine there is a lot of IP involved in that software, so you can't reuse it.

I'm hoping that the supreme court will rein in patents in Alice vs CLS Bank. The case should be decided this month.

Another problem is that some of the software will be proprietary. For example, databases are used to store information, and those database companies only give licenses for the government to use such software.

 

[nsaspook]

The complexity of many software projects are beyond a single human's ability to fully understand; as a result, cost estimation is extremely difficult. Basically, cost estimation is a educated guess based on prior history and other metrics associated with requirements.

The fact that most complex projects of any type are beyond a single human's ability to fully understand today was a given when the Pyramids were built.
I really think we have plenty of 'history' when it comes to large distributed database software projects too and a lot of that history with a certain class of software companies and government contracts is not good.

 

[SteamKing]

Something I don't understand: If the federal government has paid to create software for a health care marketplace website why can't the states reuse 90% of the same code? Doesn't code written for the federal government belong to the taxpayers?

You are assuming that the healthcare.gov website was complete at the time of its rollout Oct. 1, 2013. It was not. In particular, the payment backend where enrollees paid premiums and/or received subsidies had not been finished. All of this processing had to be handled separately from the website.

 

[jim hardy]

I'll offer no excuses for the software industry.

If you're a lucky customer you get a contractor who assigns a few guys who know what they're doing and they'll make you specify exactly what it is you want the software is to do.

All too often you get a mishmash ; in about equal proportion from both buyer's and seller's organizations; of salesmen, purchasing agents, system analysts, project managers , "High Level Big Picture" smooth talkers, contract administrators, a paper blob of memos and a computer disaster.

Too many projects start with a specification that says basically "We're not quite sure what we want but we want it big ." That invites disaster and there'll be plenty of blame to go around.

A successful computer project begins with a precise list of the inputs , the outputs, and the manipulations in between.

old jim

 

[SixNein]

I'll offer no excuses for the software industry.

If you're a lucky customer you get a contractor who assigns a few guys who know what they're doing and they'll make you specify exactly what it is you want the software is to do.

All too often you get a mishmash ; in about equal proportion from both buyer's and seller's organizations; of salesmen, purchasing agents, system analysts, project managers , "High Level Big Picture" smooth talkers, contract administrators, a paper blob of memos and a computer disaster.

Too many projects start with a specification that says basically "We're not quite sure what we want but we want it big ." That invites disaster and there'll be plenty of blame to go around.

A successful computer project begins with a precise list of the inputs , the outputs, and the manipulations in between.

old jim

Large projects will usually start off with rough user requirements that the customers hand over. These are given to a requirements team who try to map these out more precisely. They'll usually do many meetings with the customer and ask lots of questions. There are several approaches to requirements gathering, but generally it involves lots and lots of questions. At some point, the requirements team will build a prototype and present it to the customer. The goal here being to make sure the requirements are being understood correctly and more and more precisely defined.

Once the requirement team is able to map out the wanted software in terms of functional and non-functional requirements, they'll construct an SRS. All parties agree to the SRS before the project can move into the next stage. Once the SRS is completed, the design team moves into picture and works on the SDD (software design document). The design team will take the requirements and create a blueprint for the software. Afterwards, the implementation team moves into the picture and creates the code based on the design documentation.

The basic process for software engineering is:
Business modeling -- does the project make business sense?
Requirements -- work on SRS stuff begins here
Analysis -- SRS completed here
Design -- SDD completed here
Implementation - Code here
Test -- test cases reapplied
Deployment -- getting project deployed on customer infrastructure
Production -- maintaining the project

On the other hand, I am sympathetic to one notion. A lot of customers set themselves up for future disaster by blowing off the engineering component to software. Programmers out of high school are a lot cheaper than software engineers. They'll bypass that whole process above and go straight to implementation. Even some supposed "professional" teams do this stuff.

There are fairy tale myths associated with the above:
http://www.linuxinsider.com/story/73921.html

 

[nsaspook]

Large projects will usually start off with rough user requirements that the customers hand over. These are given to a requirements team who try to map these out more precisely. They'll usually do many meetings with the customer and ask lots of questions. There are several approaches to requirements gathering, but generally it involves lots and lots of questions. At some point, the requirements team will build a prototype and present it to the customer. The goal here being to make sure the requirements are being understood correctly and more and more precisely defined.

I've been in a few of those software requirements teams. This old joke sums it up nicely from my mainly hardware point of view.

Once upon a time, in a kingdom not far from here, a king summoned two
of his advisors for a test. He showed them both a shiny metal box with
two slots in the top, a control knob, and a lever. "What do you think
this is?"

One advisor, an engineer, answered first. "It is a toaster," he said.
The king asked, "How would you design an embedded computer for it?"
The engineer replied, "Using a four-bit microcontroller, I would write
a simple program that reads the darkness knob and quantizes its
position to one of 16 shades of darkness, from snow white to coal
black. The program would use that darkness level as the index to a
16-element table of initial timer values. Then it would turn on the
heating elements and start the timer with the initial value selected
from the table. At the end of the time delay, it would turn off the
heat and pop up the toast. Come back next week, and I'll show you a
working prototype."

The second advisor, a computer scientist, immediately recognized the
danger of such short-sighted thinking. He said, "Toasters don't just
turn bread into toast, they are also used to warm frozen waffles. What
you see before you is really a breakfast food cooker. As the subjects
of your kingdom become more sophisticated, they will demand more
capabilities. They will need a breakfast food cooker that can also
cook sausage, fry bacon, and make scrambled eggs. A toaster that only
makes toast will soon be obsolete. If we don't look to the future, we
will have to completely redesign the toaster in just a few years."

"With this in mind, we can formulate a more intelligent solution to
the problem. First, create a class of breakfast foods. Specialize this
class into subclasses: grains, pork, and poultry. The specialization
process should be repeated with grains divided into toast, muffins,
pancakes, and waffles; pork divided into sausage, links, and bacon;
and poultry divided into scrambled eggs, hard- boiled eggs, poached
eggs, fried eggs, and various omelet classes."

"The ham and cheese omelet class is worth special attention because it
must inherit characteristics from the pork, dairy, and poultry
classes. Thus, we see that the problem cannot be properly solved
without multiple inheritance. At run time, the program must create the
proper object and send a message to the object that says, 'Cook
yourself.' The semantics of this message depend, of course, on the
kind of object, so they have a different meaning to a piece of toast
than to scrambled eggs."

"Reviewing the process so far, we see that the analysis phase has
revealed that the primary requirement is to cook any kind of breakfast
food. In the design phase, we have discovered some derived
requirements. Specifically, we need an object-oriented language with
multiple inheritance. Of course, users don't want the eggs to get cold
while the bacon is frying, so concurrent processing is required, too."

"We must not forget the user interface. The lever that lowers the food
lacks versatility, and the darkness knob is confusing. Users won't buy
the product unless it has a user-friendly, graphical interface. When
the breakfast cooker is plugged in, users should see a cowboy boot on
the screen. Users click on it, and the message 'Booting UNIX v.8.3'
appears on the screen. (UNIX 8.3 should be out by the time the product
gets to the market.) Users can pull down a menu and click on the foods
they want to cook."

"Having made the wise decision of specifying the software first in the
design phase, all that remains is to pick an adequate hardware
platform for the implementation phase. An Intel 80386 with 8MB of
memory, a 30MB hard disk, and a VGA monitor should be sufficient. If
you select a multitasking, object oriented language that supports
multiple inheritance and has a built-in GUI, writing the program will
be a snap. (Imagine the difficulty we would have had if we had
foolishly allowed a hardware-first design strategy to lock us into a
four-bit microcontroller!)."

The king wisely had the computer scientist beheaded, and they all
lived happily ever after.

I see this creeping featureism even in industrial production machines what are being designed today. Some new machines now have a week long class just for the software interface for engineers and technicians to show all the little tricks and functions available that make it hard to just select and monitor the things that are really important in a simple 'at a glance view' without going into screens of selections and menus of cool things that clutter screens with neat popups and windows.

 

[SixNein]

I've been in a few of those software requirements teams. This old joke sums it up nicely from my mainly hardware point of view.
I see this creeping featureism even in industrial production machines what are being designed today. Some new machines now have a week long class just for the software interface for engineers and technicians to show all the little tricks and functions available that make it hard to just select and monitor the things that are really important in a simple 'at a glance view' without going into screens of selections and menus of cool things that clutter screens with neat popups and windows.

And the computer scientist was indeed beheaded. But how many people are exposed to high risk due to lax security? How did the economics play out when it came time to maintain the application? How well did the application match to the needs of the customer?

I could go on here.

 

[jim hardy]

Programmers out of high school are a lot cheaper than software engineers.

The best programmer i ever knew was a physics Phd who'd got interested in aplying computers during the Apollo projects. He taught me about basic CS concepts like re-entrancy and local vs global storage that tend to get overlooked when non-CS engineers program.

I see this creeping featureism even in industrial production machines what are being designed today.

A confession here -
my aftermarket car radio is really frustrating to me. The display is always scrolling some text about the radio station or the tune it's playing . To find out to what frequency it is set one has to watch it for longer than should be legal when driving an automobile.
I look forward every year to my grandkids' visit for they can figure out the arcane button sequence necessary to set the clock in the stupid thing (well i guess actualy it's just too smart for the likes of me).
Right now i find it far easier and less frustrating to add seven hours five minutes then convert in my head from 24 to 12 hour . Five hours five on Mountain time.old jim

 

[SixNein]

The best programmer i ever knew was a physics Phd who'd got interested in aplying computers during the Apollo projects. He taught me about basic CS concepts like re-entrancy and local vs global storage that tend to get overlooked when non-CS engineers program. old jim

A person with a mathematical or physics background could do well in computer science if he or she was willing to dedicate time to do a great deal of study. Dijkstra is the perfect example of a physicist who did well in computer science, but he dedicated his life to the field even as physicists scoffed at him. Computer science is really unique in the way it disarms people to its complexities. A person can start playing with computer science in grade school (I did); as a result, many get the wrong impression from the many layers of abstraction. In reality, it may very well be the hardest of applied mathematics.

This impression doesn't really matter when we are discussing making small scripts and programs that might be executed a few times and deleted; however, it matters a great deal when we are talking about widespread usage, and it gets even worse as complexity increases. Today, we are in a bad situation because many companies and governments got the wrong impression. So now we are seeing a great deal of economic dependencies on systems that are very insecure or unstable (not exclusive or). On top of this, we are in the middle of a quite but very real cyber war. The temptations to exploit all of these systems have been too much for foreign countries to resist.

Although the news typically reports on the loss of consumer information, the loss of business information on trade secrets is huge. China has established expert hacking groups. These groups usually consist of two teams. The technical team breaks into systems, and they set up interfaces to access the systems. Afterwards, the application domain team moves into review the targets business information. These are subject matter experts. The end result is that a business loses its competitive advantage in a marketplace from its loss of trade secrets, and they are then faced with competition funded by the Chinese government.

To make matters worse, we are very vulnerable to military cyber attacks. A lot of engineers have been hooking different parts of infrastructure into the cyber world, and they did so under the wrong 'impression.' Now, a substantial portion of our infrastructure is a sitting duck. I sometimes wonder if the nation is going to wait until we have a national blackout before people start listening to computer scientists.

In addition to security, there is also the unstable problem. We're running systems that we can't tell if their going to continue running in the next few seconds. And society has dependencies on the correctness of these systems. Just do a search for 'computer glitch' on Google news, and you'll constantly obtain news about systems failing. In quite a few cases, the result of the failure is death.

But to tie this conversation back into these health care systems, the real scandal isn't about going over budget or even over time; instead, it's about how these teams were rushed, and the impression society has about software. How many jobs do people need to lose from loss of trade secrets, how many identity thefts need to occur, how many people need to die, or how many hours do people need to sit in the dark before they catch on?

 

[AlephZero]

How many jobs do people need to lose from loss of trade secrets, how many identity thefts need to occur, how many people need to die, or how many hours do people need to sit in the dark before they catch on?

Do you mean "people", or "Americans"?

If the USA is losing its ability compete against the other 95% of the world after a few decades of domination, I don't have any problem with that. And if you can't figure out how to run a healthcare service that you can afford, that doesn't change MY life expectancy.

 

[edward]

Perhaps the powers that be should just go ahead and offshore the entire system.

Of course problems will persist anyway. Last year my wife noticed that her Bank of America checking account statements stopped arriving in the mail. After some run around at her local branch she was told the problem was at the main data processing center, and that everything was taken care of.

For some unknown reason her account statements were going to an address where my son had lived several years ago when he had a BOA account. Even though everything was supposedly taken care of her statements kept going to the wrong address.

At that point I intervened and asked the branch manager if I could speak to the main data processing center. The answer was flatly no! They communicate by computer only.

After doing a little research I discovered that shortly after receiving over $25 billion in bailout money Bank of America had moved it's entire data processing department to the Philippines.

BTW there is no way my wife is going to do on line banking. She has her own hacker protection program. She checks her account balance by phone and we have a locking mailbox.

 

[nsaspook]

http://www.oregonlive.com/health/index.ssf/2014/08/oregon_files_long-awaited_laws.html

The Oregon Department of Justice has filed its long-discussed lawsuit against Oracle America, the company state officials have accused of shoddy work on the Cover Oregon health exchange.

The lawsuit drops some bombshells. It ups the ante in the legal dispute by claiming Oracle participated in "crimes" such as wire fraud and by invoking the state's civil Racketeer Influenced and Corrupt Organizations Act, showing the state intends to prove a pattern of fraudulent enrichment at Oregon's expense.