How Kentucky Built The Country’s Best Obamacare Website

Talking Points Memo has the article How Kentucky Built The Country’s Best Obamacare Website.

From that point forward, Kentucky’s game plan for a successful website launch could be read as a counterpoint to the mistakes that the Obama administration made in building its own website. The recipe for success in Kentucky was: A pared-down website engineered to perform the basic functions well and a concerted effort to test it as frequently as possible to work out glitches before the Oct. 1 launch.

Beshear officially created the marketplace, now named kynect, on July 17, 2012, a few weeks after the U.S. Supreme Court upheld the Affordable Care Act. In October 2012, the state hired software developers to build the technological infrastructure behind the marketplace.

Testing was undertaken throughout every step of the process, said Carrie Banahan, kynect’s executive director, and it was crucial because it allowed state officials to identify problems early in the process. She laid out the timeline like this: From January 2013 to March, they developed the system; from April to June, they built it; from July to September, they tested it.
From a design standpoint, Kentucky made the conscious choice to stick to the basics, rather than seeking to blow users away with a state-of-the-art consumer interface. A big part of that was knowing their demographics: A simpler site would make it easer to access for people without broadband Internet access, and the content was written at a sixth-grade reading level so it would be as easy to understand as possible.

“We wanted it to have a branded feel, but that was not the most important part,” said Gwenda Bond, an exchange spokesperson. “The most important part was that it works. I think a lot of people would say that simplicity is good website design.

I bet they used a methodology similar to what I called top-down design and implementation.  You start implementing at the very entry point to the software.  That way the part that the user will first see can start to be tested almost as soon as the first lines of code are written.  You then fill in the missing stubs as you go along.  The part that gets the most testing is the part that the user will use most often.  If the parts at the top don’t work, you fix them first before you implement the lower parts whose design may be affected by the mistakes you originally made at the top and got to recognize and fix before you were irretrievably committed to a bad design.  Furthermore, testing and implementation can go on in parallel.  You don’t wait until all the software is done to see if any of it works.

Despite the claims in part of the article that the implementation was done before the testing, I am mpre likely to believe the part that said “Testing was undertaken throughout every step of the process, said Carrie Banahan, kynect’s executive director, and it was crucial because it allowed state officials to identify problems early in the process.”

The contractors who built the federal system are fools if their complaint was that there was not enough time for testing.  If they didn’t do internal testing throughout the process, they cannot blame their failures on the the customer.  It is up to the customer (HHS and Sibelius) to blame herself for not insisting on being able to test parts of the system in parallel with its development.

When I was at Analogy, I was responsible for designing and implementing the back end of a system.  I had written a substantial piece of my part before the front end was able to supply me any data to test my part.  As part of my development, I wrote a very crude front end to provide me with enough data to test my part.  In fact there was a middle part between me and the front end.  The middle part did not get designed (let alone implemented) until I could hand a completely designed and partially working back end to the designers of the middle part.

Good old principles of software engineering.  What I used to call risk minimization was often ridiculed in comparison to what I called risk maximization of the projects that usually failed.  Of course the rewards go to the people who screw up the software and then make a heroic effort (we called it a diving catch) to rescue the project.  If the project works well when you release it, then it couldn’t have been that difficult to do, so there is no point in rewarding people for doing something simple.

Luckily  for my morale I was self motivated,  Doing a good job and having satisfied customers was enough for me, no matter what the bosses did.  Not that I am saying I was poorly paid.  Although I did learn the lesson that I would never get rich being an employee.  I needed to be an owner instead.  I didn’t get rich being a stock owner, but I was able to retire comfortably.  If I had learned the lessons of stock ownership 20 years earlier than I did, I might have been rich by now.

Leave a comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.