There's now an even closer comparison available: the college Common Application. Created to facilitate reusing data and admissions materials across multiple college applications, this year's Common Application, which services 517 colleges and universities, has become a technological fiasco thanks to the interaction of two famously inefficient parts of the (mostly) private sector: programming contractors and educational administration. They came together in the form of the nonprofit membership association Common Application Inc. (I will use "Common App" below to refer to the company.)

On Aug. 1, this year's upgraded Common Application software rolled out, consisting of a major overhaul to the application process that was, according to Common App senior director of policy Scott Anderson, "a completely new system built from the ground up." It immediately crashed.

Common Application's Facebook page has been barraged with complaints. "The only browser that worked for our counselors was [Internet Explorer]… Support was never helpful. We never heard anything from anyone regarding our issues," said Facebook user and Common App guinea pig Chleo Harley. "It's been a nightmare," said Cornell associate vice provost Jason Locke to the New York Times.

Anderson, however, maintained that the delays were unnecessary. "Nobody had to move their deadlines," he said. "The colleges that moved it beyond Nov. 1 did so to help ease the anxiety that applicants were feeling that they might not possibly be able to submit their applications because of problems they were experiencing."

Applying to college shouldbe more like filing taxes than buying from Ticketmaster.

Easing that anxiety should have been the job of the Common Application, not of the member colleges. The complaints are justified. From an engineering standpoint, what happened is ridiculous. The parallels with healthcare.gov are evident: A system designed to serve as the broker between consumers and hundreds of companies fails to get the connections right.

After two months of eliding the blatant problems, the Common App folks did become more upfront about the problems, posting a partial list of fixed bugs and a list of bugs to be fixed, as well as a pledge to rebuild trust. But healthcare.gov was an entirely new system built from scratch; the people behind Common App—a nonprofit with a board of directors drawn from a dozen or so colleges—took a working system and, in the process of "upgrading," broke it.

I worked primarily on servers in my time as a software engineer, and there were some pretty simple rules of thumb when upgrading. Whenever possible, you roll out a server upgrade to a fraction of your users first, to make sure it doesn't instantly break. This is sometimes called the "canary" server, as in coal mine.

If it does break, you make sure to have a process in place to roll back the upgrade and restore the system to its previous state—the one that was working. The same goes when you roll out to everyone: If something breaks, you roll back so you can find the problem and fix it off the clock, without users and managers pointing at their watches asking when things will work again like they did yesterday.

Sometimes, for technical or logistical reasons, canaries or rollbacks aren't feasible, and those times keep antacid companies in business. There is nothing that gives an engineer more heartburn than removing the margin of error. When I asked Anderson if Common App had ever considered rolling back to their earlier, working system after the instant crash on Aug. 1, he flatly said no.

The total meltdown didn't have to happen. A pilot program should have shown the errors in the new Common App software. They should have retained the paper applications for at least the first year of the new system. And when problems did pop up, everyone should have been prepared to use last year's software as a fail-safe. But because the project was managed incompetently, that wasn't an option.

"Incompetent" might sound harsh, but if you are working on a major upgrade without contingency planning for bug and failure scenarios, you are not managing the project competently. Bugs always happen.

(OK, I have seen instances in which upgrades went utterly smoothly. Yet in every one of those rare cases, people had made extensive contingency plans in case something went wrong. Coincidence?)

Common App uses the educational software contractor Hobsons, which in turn is owned by right-wing British tabloid the Daily Mail. They seem to have avoided the opprobrium directed at the Common App, though they were responsible for the development itself. Anderson directed me to them for all technical questions. All he could tell me was that Hobsons' testing was "industry-standard as far as the ratio of developers to Quality Assurance folks." Mr. Anderson, a ratio does not good software make.

Forbes reporter Susan Adams was unable to get anything from Hobsons CEO Craig Heldman beyond some vague reference to "unexpected challenges." Translation: You need us more than we need you.

Likewise, Common App's refusal to say when things will work is pretty brazen: "Your requests for precise timelines are understandable," wrote director of communications Aba Blankson to users on Oct. 18, "and we would provide such details if we could. To do so, however, would be to make commitments that we might not be able to honor." (I can't wait to try this line out on my editor.)

Anderson claimed that Blankson's absence of a timeline was not as frustrating as it sounds, as all "systemic" issues had been fixed at this point. When asked what a "systemic issue" was, he described it as "an issue that's affecting a large percentage or even a majority of users." Which is a bit like the airline telling you that your lost luggage isn't a big deal because it's not a "systemic" problem.

Rest easy, high school seniors, a majority of applications are getting through! Let's look at it a different way: Under Anderson's standard, it's more likely that you'll run into a Common App bug than that you'll get into Harvard.

I do not find Blankson and Anderson's complacency surprising. Common App doesn't need to beg forgiveness, because they have a captive audience: While hell hath no fury like the parents of a college applicant scorned, too many students are already locked into the system. Common App's generally desultory attitude toward customers is symptomatic when a monopolistic middleman has control over a scarce product, in this case college acceptances.

Explaining why no phone support will be forthcoming, Common App issued an Oct. 18 "Statement of Commitment": "Given the volume of users who interact with our system, phone support would immediately become unsustainable." For "unsustainable," read "unprofitable."

The worst aspect of the Common App's monopoly is its use of "exclusive" carrots, offering discounts and other perks to colleges that agree to use the Common Application as their only way of applying.

Independent educational consultant Nancy Griesemer, whose coverage has been excellent, has described in detail the pressure and enticements put on colleges to go exclusive—more than a third of the 517 did. They are now stuck with Hobsons' Choice: to take it or leave it.

With any luck, this imbroglio will put a damper on the Common Application's bid to become the Ticketmaster of college admissions. Applying to college should be more like filing taxes than buying from Ticketmaster.

A monopolistic middleman has every incentive to rip you off and underperform—even a nonprofit like Common App, which aggressively pushes exclusive contracts in order to overpay incompetent contractors for inferior work. Unfortunately, the Ticketmaster model is more lucrative, and so it dominates.