HealthCare.gov

Did agile processes contribute to HealthCare.gov's problems?

The well-documented critiques of the front-end and back-end software on HealthCare.gov beg the question of whether this critical site was properly designed — or, even worse, designed at all. 

It has been reported that the front end was designed with an agile process; unfortunately, most agile processes reject and discourage “big design up front.” In a nutshell, many agile processes — and especially extreme programming — reject the big design phase as part and parcel of rejecting the waterfall methodology. Agile processes follow more of an “organic” software development, where developers start coding the smallest increment possible and “grow” the working software up, little by little, with constant customer feedback. These agile methodologies call for “user stories” to design each small increment of the system being developed. To be fair, agile can work for some software projects, but I assert that it is the kiss of death for projects with many moving parts, multiple organizations and complex interactions. 

Personally, I am a fan of design and system architecture, and I have witnessed many successful projects that resulted from good design. Furthermore, I flatly reject the notion that user stories can suffice for large IT projects like HealthCare.gov that require scalability, data integration, numerous system interfaces and other complexities. These need to be designed up front or the results can be disastrous, as the HealthCare.gov launch demonstrates. Where is the documentation for this system? I just submitted a FOIA request for it and will report on the results once I get a response.

The assertion by federal CTO Todd Park that volume was the only reason for the failures is a weak excuse at best, because designing for scalability (or better yet, designing for elasticity) should have been an obvious upfront requirement. For example, if HealthCare.gov uses a synchronous interface, as reported by Paul Smith, then it was not architected properly. Given that developers had three years to prepare for the Oct. 1 launch, improper design is inexcusable.

The Health and Human Services Department should come clean on these deficiencies for the sake of the rest of the federal agencies that could learn from its mistakes. Those who never admit their failures will never learn from them. Other federal agencies need to learn from HealthCare.gov. Those painful lessons on system design (or the lack thereof), system architecture (or the lack thereof) and elasticity (or the lack thereof) might then not be repeated.

About the Author

Michael C. Daconta (mdaconta@incadencecorp.com) is the Vice President of Advanced Technology at InCadence Strategic Solutions and the former Metadata Program Manager for the Homeland Security Department. His new book is entitled, The Great Cloud Migration: Your Roadmap to Cloud Computing, Big Data and Linked Data.

Reader Comments

Thu, Dec 5, 2013 Cookie

@Cory you are correct. Apparently the changing requirements were a big part of the reason they could not deliver a working system. Nevertheless, they took TENS of MILLIONS of dollars in taxpayer money and said they could deliver a working product. For 60 million dollars or so...they could have hired testers themselves. The developers could have written test programs to exercise the site. They could have sent a guy to sit in congress every day and keep up with the hearings. They probably could have paid a lobbyist to try to influence the outcome. What did all of the money get spent on? Health care and other government services are vital...and millions depend on them. Nobody (except maybe advertisers) depends on Google or Amazon. I've worked on automating many systems and one thing that is a great idea is to have a manual backup procedure for critical systems. I think this is a must for processes that can't afford to wait if a server goes down. Unfortunately in this case, the software did not work, but there could have been other issues. If there is a deadline, then people should be able to sign up no matter what. That could have saved some face at least. Also, LOL @ the NSA comment.

Tue, Dec 3, 2013 Adrian Carr KNoxville, TN

Wow. All I can say is that the author has no clue how a good agile team develops software for complex sites. Here's a clue: In addition to user stories, there are system designs, architecture, scalability requirements, integration requirements, testing plans, and more, typically documented.

Tue, Dec 3, 2013 tweet_the_judge Austria

They used Waterfall for this project - Not Agile. Amazing.

Sun, Nov 17, 2013 DW

You have made a flawed assumption that architecture and design are not part and parcel of an agile methodology. Nothing could be further from the truth, except, perhaps , in a style bastardized by the government. There is nothing wrong with the methodology, though, so you should have done your research before smearing it.

Fri, Nov 1, 2013 Mr. Sarcastic

I really don't know why a website was even required. NSA could properly assess your needs as well as your ability to pay from your captured "metadata" and decide what plan from what insurer was right for you. I ran that dialogue through my head and it was quite amusing. I may send it off to Jay Leno for a part of his monologue. The bigger question is...What WAS the actual price paid and where did the money go?

Show All Comments

Please post your comments here. Comments are moderated, so they may not appear immediately after submitting. We will not post comments that we consider abusive or off-topic.

Please type the letters/numbers you see above