No, HealthCare.gov Doesn't Require 500 Million Lines of Code

itwbennett writes: "Half a billion lines of code for a transactional website — more than five times as much code as that behind OS X — just didn't pass the sniff test. But just how many lines of code does it take to generate HealthCare.gov? This question came up on Reddit again last week and it appears that we may now have an answer. One commenter who claimed to have worked on HealthCare.gov as part of the post launch clean-up crew at the end of 2013, provided counts of the lines of code behind HealthCare.gov, broken down by programming/markup language."

A reddit link?

[Anonymous Coward]

Wow, full circle. Slashdot stories are now reddit links. Not implying anything. Just wow.

Re:A reddit link?

[Anonymous Coward]

Not only that, but you need to go to the link to get the number. They could have just posted that in the summary. Typical click bait. Fuck 'em

Posting AC due to recent politically motivated mod bomb attempts on my account. Fuck the moderators also

-F

Re:WOW

[thedonger]

Forget about the number of lines of code. I work for a U.S. company that builds healthcare.gov type web sites and the reporting back end for large companies. The estimated price tag of the front end ($150 million or so) is about 20 times what the tax payers should have paid. Add in the back end reporting to the insurance companies and billing, throw a call center in at least two different time zones, main and backup datacenters and instead of the full price tag ($600 mil?), let's say at the high end $20 million for the whole thing. Ongoing administration costs maybe in the 7 digits per year. The whole thing was a sham to get votes and fill the coffers of some cronies.

Even 10MLocs would be outrageous

[Anonymous Coward]

Me and my 120 developer colleagues are able to make software for 40 hospitals, covering about every bit of information you can imagine, in less than 10 MLocs (I counted 4.7 real code MLocs four years ago, might be 10+ now because of migration to other language/environment and new features). 500M for a website isn't possible. Period.

Why So Many Programming and Scripting Languages?

[Anonymous Coward]

Language files blank comment code
Java 13481 419643 847982 2399683
HTML 1635 50124 16845 515494
Javascript 1631 56298 102140 322192
XSD 5227 1238 20945 156696
XML 659 6436 13073 136827
CSS 205 14000 9420 109815
Maven 275 737 1421 47449
XSLT 383 2357 1476 21624
Bourne Shell 248 2305 1446 8830
SQL 28 860 139 8487
JavaServer Faces 35 766 0 3770
DOS Batch 48 235 118 849
Ant 8 77 45 810
Perl 18 161 45 646
Visualforce Component 39 0 0 626
Groovy 4 68 15 361
Python 5 55 90 263
Visual Basic 1 3 0 25
DTD 1 8 0 17
JSP 3 0 0 13
ASP.Net 1 0 0 11
SUM 23935 555371 1015200 3734488

Holy Christopher Columbus! Was it bring your favourite programming language to work month?

Re:$1.2B/3.7m =

[NicBenjamin]

Where do you get $1.2 Billion?

As of December it was $319 million or so. And that includes a lot of non-technical stuff.

Re:$1.2B/3.7m =

[NicBenjamin]

Goddamn I thought I typed that link right. But this is the source for $319 million:
http://www.washingtonpost.com/... [washingtonpost.com]

Re: So now we're trusting blogs face value?

[Anonymous Coward]

I can confirm Alex was one of about 6 good CGIFederal coders on the hc.gov effort, and generally a good guy. He was working on SHOP (the small business market) before it got cancelled and him redirected to bug fixes. I haven't counted the lines of code on the sustenance7.0 branch, but it's probably in the ballpark. Posted AC for obvious reasons.

Re:WOW

[ArcherB]

Finance guys are so cute.
I was an IT guy so....

For example a retail bank needs two tables in it's accounts database. One for the account, a second to record the transactions.
The DB needs a customer table (name, address, phone, address, ect), transaction table, account type table, account table, interest rate table, payee table, payroll tables (complete with more account data from other banks, employee names, etc) etc. There's a LOT of data involved, and this still doesn't include the cutesie stuff banks throw in like customer preferences.

The database may be queried by other databases (ie: the guy approving loans), but it is not actually a part of those databases.
Actually, different systems maintain different databases. For example the Internet Banking side will maintain it's own database. the ATM side will have it's own side. Then there's the credit card system, ACH systems, wire systems, the core system itself and others. All of these systems must interact with eachother. For example, the a customer may log into the Internet banking side, which will have to hit the core to get the current balance, EOD balance from yesterday, unprocessed transactions, processed transactions, interest rates, any messages from the bank, and so on. It also has to be able to inject transactions such as payroll into the core system, wires into the wire system and so on.
Of course, all of these systems are different. The ACH system uses a flat text file. The core is usually an UNIX based system with a terminal interface. The Internet Banking is probably an Apache Tomcat connecting to a MSSQL system. Then, there is the bank end that is comprised of DB front-ends, screen scrapers, batch files, transaction injectors and so on.

You could probably convince a bunch of PHB-English Majors your database is more complicated because you have six different, totally unrelated databases in the same file, but don't try that shit in front of engineers.
Not just different DB's but completely different architectures. And, of course, different states have different laws. For example, all states that take income taxes have a different method to pay them. Then their are business taxes, both federal and for all 50 states, loan laws, interest rate laws etc.

And there is much much more, but this is getting out of hand. Suffice to say that you have no friggin' clue as to what you are talking about when it comes to everything a bank does, much less when it comes to tying all those systems together.

Compare that to the ACA system which involves user data, finance data, what companies are available per state, what plans available per company, and an interface system to communicate between the handful of ACA authorized insurance companies per state and the back-office system. Many states run their own system. The government has claimed that their system doesn't even keep the data!