"Why," Politico's Dylan Byers asks, "didn't the White House use WordPress" to create Healthcare.gov? Before we answer that question, let us dismiss it. That is a deeply bad question. The stumbles of the highest-profile website launch in political history have revealed that it isn't only the Obama administration that's trying to get its head around web technology. Reporters and members of Congress are, too — which is a problem for their constituents.

Not to pick on Byers unnecessarily, but his piece — which is here — immediately reveals that Byers doesn't really know what he's talking about. It's a little-acknowledged secret that people writing for the web often need to get up to speed on complicated topics fairly quickly. Sometimes they (we!) miss the mark in obvious ways. Byers, not known for his data acumen, missed the mark.

Healthcare.gov is a necessarily large and necessarily complex aggregation of code. Much has been made of its size — 500 millions lines in total, according to The New York Times. That number alone spawned quizzical skepticism from political reporters. That nice, round, half-billion figure is appealing as a topic of conversation. If it is accurate — a representative of HHS didn't respond to requests for clarification from The Atlantic Wire — it tells us that the site is larger than most sites, and not much else. And even that is just an assumption! It depends on what is included in the "code."

Above, we used the term "aggregation." Healthcare.gov includes a ton of different files (some, from the publicly available codebase, are at right) and a number of different coding languages. Earlier this month, The Atlantic Wire spoke by phone with Dave Cole of Development Seed, one of the companies involved in creating the site. He explained that their company was involved in building the home page, which used a tool called Jekyll to create static web pages. (Static pages are ones that don't need to be created on the fly by a webserver when a visitor comes to the site, meaning they load faster.) What counts as code here? Does the Jekyll tool? Does the content that's used to create the static page? The dynamic content was built using Ruby, a coding language that's very common in web development. The scripts that generate the dynamic content counts as code. All of the output doesn't. Does some?

Our IT team for The Atlantic Wire estimated that the codebase our site alone uses is about 180,000 lines. But our stories are shared by our sister sites (TheAtlantic.com, NationalJournal.com, and so on), and there is code on those sites to display our content. The 180,000 figure also doesn't include our content management system, called Django, or other code libraries that the site uses. In total, this site uses about 1.8 million lines of code. But that doesn't tell us much.

It gets worse. An excellent article at Slate dives deeper on this, but consider that each of the three lines below counts as a line of code — and each is part of displaying this page right now.

var t, js, fjs = d.getElementsByTagName(s)[0];
<!-- BEGIN: Welcome Screens -->

The first and third are HTML, hypertext markup language. The second is a line of Javascript. The first snippet says "what follows is Javascript, not HTML." The second sets three variables based on page content. The third does literally nothing — it just helps the programmer know what's going on. But all three are included at some point in the 1.8 million tally.

Exploring even that one snippet of one story shows why this isn't an easy topic to tackle. But it isn't why Byers' question doesn't make sense. One commenter on his piece, "myerman," points out that it almost certainly wasn't the website that cause Healthcare.gov to choke — it was the website's attempts to connect to the myriad databases it needs in order to verify personal details and get insurance plan costs. In its interview with Harper Reed, the guy behind the Obama 2012 campaign site, Mother Jones echoes that point. The problem with scale was likely as much internal — integrating government and insurers data — as external.

Byers' question — why not build in Wordpress? — was prompted, it seems, by a conversation with Peter Slutsky. Slutsky works for Automattic. Automattic runs Wordpress. Wordpress is a great tool for building scalable websites quickly — particularly sites with a lot of regularly updated content. Blogs, for example. It's known for its content management system, though that's not all it does. But the problem with Healthcare.gov was never its content management, it was at least in part due to the interplay with myriad existing databases. In only the most basic sites is Wordpress anything like plug-and-play. There's almost always customization required — meaning, in this case, a substantial amount of coding. Millions of lines, no doubt. Could Wordpress have worked better than the existing system? Maybe! But a number of other tools could have perhaps worked better, too.

Clay Johnson worked on the Obama campaign site in 2008. He was watching Thursday's hearing, including its own moments of confusion over technical issues. Johnson's been pushing for more analysis of why the firms that built the site were selected, pointing at the fact that the government is hamstrung by procurement rules meant to ensure that government officials aren't steering contracts to friends. This was his analysis at the end of the hearing, after several hours of members of Congress asking questions that, Johnson felt, didn't do much to uncover where the breakdown occurred.

To fix a problem in technology, you have to isolate the problem, as you would a problem on your computer. Is your cable modem down? Your router? Your wifi? Your browser? Once you find the problem, you can fix it. The teams that built Healthcare.gov and whatever partners are included in the support "surge" are currently identifying points of failure (Code? Server scale? Both?) and fixing them. While it may not make sense for reporters to know how to code, it does make sense for them to know what questions don't make sense.

The Clay Johnsons and Harper Reeds of the world know a lot about how websites are put together, and neither suggested that the main problem was technical. Each in part blamed the system under which the site was built. It's also probably because the actual problems are deep, technical — and, as with any new big site, inevitable at at least some scale. That's a dull story. It's one grandstanding congressmembers and tech-naive reporters don't tell, and so it's not the one that voters and readers hear.

Update: 10:30 p.m.: Johnson and Reed wrote an opinion piece for The New York Times that provides a longer overview of their procurement argument.

Correction: As if to prove the point, the original article referred to Ruby as PHP-based. It isn't.