After reading that article, I would be even more worried about healthcare.gov.  It appears that they have focused on fixing the front end scalability, while ignoring the back-end problems.   That again appears to be a political decision, not one based on engineering concerns.  As usual.
This is a really bad idea.  The slow performance of the front end has actually been a godsend, because the back end has been generating errors that the insurance companies have been forced to deal with manually.    They can do that when only hundreds of people here and there are registering.  But if they throttle up the front end without fixing the back end, there’s going to be hundreds of thousands of incorrect registrations - all of which are going to have to be corrected by someone by contacting the insuree and getting the proper info.  That can be done by the hundreds or thousands, but not by the hundreds of thousands.
Also, anyone with experience with systems like this will tell you that the most devilish gremlins lurk in the back end, and the worst of those are the ones that appear under load.  That’s when you start getting into thread contention problems, race hazards,  failed transactions, memory leak failures, and that sort of thing.    These are the problems that happen sporadically and mysteriously - the system is working perfectly, then suddenly it crashes and you have no idea why.   If you take the system down for testing, the problem goes away.  Bring it back, and it fails randomly again.
The last thing you want to do is fix bugs like that in a live system, because the way you need to attack them is often to set up runs of dummy data at high load, and hit the servers in predictable ways so you can retrace exactly what happened.   But these guys decided to try to fix the system while leaving it running - another decision forced by politics and not engineering.    And because the front end problems have throttled the entire system, they haven’t even tested the back-end code under a proper load.
In the real world outside of government,  you would typically build the back end completely separately from the front end, and build test frameworks that could simulate any kind of load you needed so you can test the back end to failure.  You need to build the system in debug mode  so you have documented stack traces, breakpoints on memory or events, source debugging, and can trap more exceptions and report them.  But you don’t run debug code on a production server.  For one thing, it creates security leaks.  It’s also slower and can mask other problems.  So these guys are either going to be trying to debug the back end without access to proper debugging tools, or they’re going to be using debug builds on a production server.
This thing is a clown show from top to bottom.  I’ll bet when the engineers were told that they would not be allowed to take the system down to do proper fixes they walked out of that meeting shaking in anger - or crying.