Here is an interview with Robert N. Charette.

I haven’t seen any indication of who’s doing the configuration management. Typically in a large system, you have a master configuration list and a change control board, so people can say, “This is what you’re going to change; this is what the effects are going to be.” And it’s a fairly rigorous process, especially if you have a system that’s very complex like you do here. What you don’t want is somebody making a change that nobody else knows about. Just getting hold of who’s doing what to what, and understanding what the implications are is itself going to be a huge undertaking. For every bit of software, you want to have some release control. I haven’t seen anything to suggest that type of management. But then again the management has been extremely opaque.

I disagree with his conjecture. I was thinking the other day that they must have really good configuration management in place, or else the thing would have blown up already with all the fixes that they are putting in. You would be seeing things like

When MailOnline visited the website shortly after Carney’s daily briefing, the Obamacare portal spewed a nonsensical mixture of computer code instead of a typical login screen.

Gone were words like ‘Username’ and ‘Password.’

In their place were jumbled programming strings like ‘???ffe.ee.myAccount.login.username???’ and ‘???ffe.ee.myAccount.login.password???’

Oops, well maybe Charette is right. But anyway, I was about to say:

A computer system is not like a house, where you make fixes to the house by hammering nails directly to the actual house. Instead, think of having three versions of the house. You hammer your nails into a development version. When you think it is fixed, you call it a test version. When it’s been tested, you replace the defective house with the test house. When the new house goes “live,” it is called the production version.

I can imagine that back in early October, when things were just awful with the production site, they cycled from development to production pretty quickly, because they needed to show improvement. But my guess is that they have stopped doing that, and that now they are taking more time to test stuff before they release it.

In fact, it could be that by the time the chief fixer, Jeffrey Zients, came on the scene, the development version had most of the known issues taken care of. However, rather than put that version into production, they set a release date of November 30th. Some time before then, they will freeze (or have already frozen) that version and have it moved over to Test. They will try to rigorously test the Test version, which will result in a list of problems found during testing. They fix simple problems right away, and they defer complex problems until a later release. Then, on November 30th, they move the test version into production.

I am oversimplifying things here. But my main point is that I bet that there is more technical competence on the project than some critics are inclined to give them credit for.