(If you are a developer for a health insurance company looking for details on this project, you’ll find that towards the bottom)
Let’s face it, some code is more fun than others. Especially when you get to create a brand new project from scratch. For me, it’s even more fun when there’s no UI to make “pretty”. And that’s exactly what I got to write over the past week.
It was a simple project with a terrific opportunity to write some amazing code: Take some CSV files and convert them to the format outlined here. Add bonus points for going well beyond the validation requirements in the spec.
In the end, there were 1764 lines of code, with 76 passing unit tests achieving over 98% code coverage. There’s also zero duplicate code and, for me, at least, some decent metrics upon analysis.
Show me the data
(For all of the following metrics, I’ve removed irrelevant types that might unnecessarily skew the results)
Sorting by maintainability index in ascending order below, we see that there’s nothing below 54. Cyclomatic complexity, class coupling, and lines of code look great at this level, too.
Sorting by cyclomatic complexity in descending order below shows that nothing is above a 31. Maintainability index is excellent across this range. While class coupling looks high in a couple of places, note that those rows are entire types (classes), not members. To me, that looks good.
Sorting by class coupling in descending order below is what bothers me the most. I don’t actually know if those numbers are good or bad. You can definitely see which types are the heart of this application. And again, most of the rows in these metrics are types, not members.
Sorting by lines of code descending below looks pretty good to me as well. Mostly a bunch of types. The biggest member has only 17 lines of code. That does seem high though… maybe I’ll fix it after I post this.
And just to be complete transparent, here’s the code coverage results..
Total line numbers…
Apparently, there are a lot of health insurance companies out there right now that are struggling to prepare these JSON files for CMS so their provider/formulary system will work for open enrollment which starts next month. Last I heard, the files are actually due by close of business today.
The spec doesn’t even fully state the requirements. You also have to prepare an index file and make sure you’re serving the files over SSL (why are there two similar, but definitely different spec pages like that?!?!?).
How complicated can it be to create a bunch of JSON files though? Turns out, more complicated than usual. Convert the 200kb worth of CSV source files through my program yields over 10GB (!!!!) of JSON data. It’s a process that takes several minutes on my BEEFY laptop with a SSD and 32GB of RAM. On lesser computers, the program simply pukes with an OutOfMemoryException.
My code fully validates the JSON structure against the CMS spec and goes the extra mile to validate URLs, email addresses, states, NPIs, and more.
That’s just the beginning, really. The program is configurable and easy to use, but there’s an underlying API that can be used to fit your own company’s needs, while still producing the quality output that CMS requires.
It may be too late, but I’m putting this post out there in hopes that I might be able to help some health insurance company who is struggling to complete this project. If you are interested in this project, reach out to me ASAP so we can discuss how to make it happen.
And now on to the next big project.