There is an old saying, fools tread where angels fear to go. Forgetting for a moment what ObamaCare would do to the economy, a look at the Software that ObamaCare is dependent on shows ObamaCare can not survive as is.
A little background first, I have been developing Software for over thirty years, the last ten have been doing web applications. I have also written a book on Web Application Frameworks. One interesting statistical fact is that only 1/3 of Software Project are considered successful.
See the Chaos Report http://www.csus.edu/indiv/v/velianitis/161/ChaosReport.pdf.
Of the Projects that are considered a failure, 1/3 are delayed or require major rewriting. The last 1/3 are eventually cancelled. A position I once had dealt with Reviewing a Project that was in trouble (a State Government Project). I was in the unfortunate position to tell the management that the code would never fly and they were better of scrapping the whole thing and starting over rather than trying to fix it. I even had one of the development managers try to ask me “Would it surprise you if I told you that it was working.” My response was simple, how many users where you testing with. The software worked fine as long as there was only one user. But once you put a few users on the system, it died.
There are three things that often cause the collapse of large software projects. The first is memory management. Second, Database design, and finally System Integration. For what I have been able to glean from the little information I could find, all three of these are likely issues with ObamaCare software.
Memory Management: Many developers have the false impression that you can just throw more memory at a problem rather than worry about how much memory is being used is Something called the session. Leaving too much information in the session is referred as Session Pollution. The fact that the system has been crashing with a small load, suggest that the application has Memory Issues.
Database design. This is a little harder to tell, but the mere fact that the system was thrown together so fast it is likely.
Finally, System Integration. Consider how many government agencies that ObamaCare must integrate with, including Software that has had troubles for some time shows that the System Integration is a problem. Take for instance the Integration with IRS. The IRS computers has been famous for their failures. Further, there is the issue of latency. Latency, is the problem where information must be retrieved from the another System. Latency is the amount of time it takes to go from one system, retrieve the information and return. Consider the number of Systems they need to integrate with and consider the errors that are being received by the Users.
Then there are the issues of the Requirements, or in the case, the Regulations where not even written until some time in 2013. Add on top of that, the fact that the code was delivered for testing on 30 days before the code was to go live.
Then there is the technical leadership. Normally, a major project is contracted out to a Major Government contractor and then parts are sub-contracted out. However, in this case, the decisions makers where in the HHS department and not with the Contractor. Add to this the lead contractor experience was developing the Canadian Single payer system (CGI) and had apparently little experience developing a system this large. The fact is, almost no one has ever built a system this large in such a short time (3 Years).
Some have suggested that the Project should have been given to a company like Google or Facebook. However Google and Facebook are completely different animals. They have some great technology, but they are not business applications. The only thing that comes close to anything as large as ObamaCare software are systems like those at Bank America, FedEx, Version or other such companies. However, these systems while large where not developed over night. The evolved over a number of Years.
Bottom line, it is unlikely that the Software for ObamaCare will work anytime in the near (or far future). They will eventually come to the conclusion that the system will not work and they will have to scrap it.