When the Affordable Care Act health exchanges rolled out on Oct. 1, we tried to sign up for a small business plan on the Covered California site, but like millions of other Americans, we were met with frustration. The application wasn't accessible for the first day and a half, and the web site was littered with bugs like incorrect field validation and broken links. Worst yet, the process ended with us submitting an application which had to be reviewed before we could see any quotes. That was 13 days ago, and we haven't heard anything since.
And it's not just small businesses, or users in California. A New York Times researcher attempted to register more than 40 times from Oct 1 - 12 and was never able to log in. And a CNN senior health correspondent tried every day, even during the "wee hours," and couldn't log on until day 14 of trying.
The Affordable Care Act health exchanges are an understandably massive undertaking -- healthcare and insurance software are known for extraordinarily complex regulatory, privacy, scale and integration issues. But still, it's frustrating to watch such high-profile problems affecting millions of Americans. And from the perspective of an Internet startup, many of the problems could have been reduced or avoided altogether had a software architect from a startup been consulted while the legislation was being drafted.
1. Large-scale Software Projects Are Still an Uncertain ArtIt appears that Congress determined what they wanted and when they wanted it, then tasked the Health and Human Services Department and contractors to build the system, but people in the software industry could have told you that is a dangerous approach. High-profile successes like Apple and Google might give the appearance that if you have an idea, it can be built, and all you need are engineers to make it happen. What the public doesn't know is that for every software startup success, there are dozens and sometimes hundreds of failures, and many companies fail because they aren't able to build the product they envisioned. Building large-scale software systems is still filled with the risk of failure, and so a project's design and rollout cannot be centered purely on economic, political and public objectives. From the earliest point possible, you also need to prioritize how you manage and minimize the software technological risks.
2. Even Successful Software Companies Have Problems Serving MillionsEver seen the Twitter Fail Whale? The social microblogging site launched in 2006, but even in 2013, the happy whale continues to appear on the home page at times stating that the service is over capacity, leaving its millions of users unable to access their own feeds. Signing up 48 million uninsured Americans is an enormous challenge for any software company, and planners -- and critics -- shouldn't assume that the system could be built easily and quickly. If the requirements came to the engineering teams months late, that doesn't mean you can make up the time during the research and engineering phase; more likely, it means that engineering will need additional time, as well.
3. Startups Know That Software Schedules Are Notoriously TrickyAccording to the New York Times, "One person familiar with the system's development said that the project was now roughly 70 percent of the way toward operating properly, but that predictions varied on when the remaining 30 percent would be done." But there's an adage in the software industry that what appears to be the last 15% of the project actually constitutes 85% of the work. So if planners believe the project is "70% done," this could take a while. And it may not be easy to speed things up; engineer Fred Brooks explains in the software engineering classic, The Mythical Man-Month, that once a project is started, adding more people may not help, writing, "Nine women can't make a baby in one month." So, the health exchanges simply may not be able to come to term by the Dec. 15 deadline.
4. Software Startups Build a Viable 1.0 FirstBecause software projects can be filled with so much uncertainty, startups often first build what is called a minimally viable 1.0: What is the smallest version of the solution that will solve the users' problems?
Getting a smaller product out there earlier informs you of what your issues are going to be. For example, had the Affordable Care Act been required to launch a simple informational site a year ago, even that simple piece could have helped designers understand what the primary areas of confusion and demand would be.
5. Software Startups Iterate and LearnAnother reason startups launch a minimally-viable 1.0 is to learn from their mistakes. Before you even have a product out, you don't know what parts are going to be most-used, and you don't know what your major problems are going to be. For example, when we launched CostHelper in 2006, I didn't know at the time that dealing with user comment spam would become such a major, time-consuming, ongoing effort.
The Affordable Care Act's exchanges -- launching simultaneously in all states with a variety of offerings and tiers from a large number of carriers -- feels more like a fully-featured version. By condensing so much functionality into one round, they're losing the opportunity to face challenges and solve problems one at a time.
6. Software Startups Hire the Best EngineersGiven the success of existing Internet companies and the legions of exciting new startups, it's no surprise that there's an intense, competitive rush for top talent. According to Twitter's IPO documents, their vice president of engineering was paid $10.3 million, just less than the CEO. And corporate on-campus recruiting events for software engineers have become so well-known for their freebies that it's become a tactic for non-engineering majors to go to computer science recruiting events to scavenge for free food like pizza and even sushi.
Although the Health and Human Services Department and contractors CGI Group and Booz Allen Hamilton probably have many dedicated and able engineers, it could be difficult for these firms to compete with Internet companies for the top engineering talent with experience in high-demand areas like launching new consumer Internet products, building intuitive and easy-to-use services, and designing and operating massively scalable consumer websites.
7. Someone Needs to Ask the Engineers About the ScheduleOne of my old software managers who previously worked at Hewlett Packard took the following approach to scheduling a new software project: Each meeting, he'd ask the lead engineers how long it'd take to develop one component. Then, he had the team collectively estimate how long integration and testing would take, added the estimates together, then doubled the total, adding, " how can you know how long a project is going to take if you don't ask the people who are actually going to build it?"
8. Software Products Go Through Beta TestingOne lesson software companies have learned is that it's very difficult to anticipate the myriad problems that can arise with a new product, so beta testing has become standard for product launches. Before Microsoft releases a new operating system, or Google launches a new service, they give away free products or early access. Imagine the number of problems that could have been anticipated if The Affordable Care Act had incorporated a three month beta test period where a small number of volunteers in each state signed up for insurance before the nationwide release.
9. You're Supposed to Have a Clue If You Can Launch on TimeThere's an entire field dedicated to tracking the progress of software projects, to help managers track schedules and anticipate delays early enough to inform senior managers and take corrective action. Even on Oct. 1, President Obama seemed unaware of the scope of impending problems, calling the problems glitches, and comparing the rollout to the release of Apple's iOS7. "Consider that just a couple weeks ago Apple rolled out a new mobile operating system," the President said. "And within days they found a glitch, so they fixed it. I don't remember anybody suggesting Apple should stop selling iPhones or iPads or threatening to shut down the company if they didn't."
It's one thing for a software company to run late, but people in the software industry have learned you have to manage an environment where you accurately track progress, where managers can communicate truthfully how a project is going, and where the organization as a whole understands that you may need to adjust plans based on delays.
And the top reason why Obamacare should have been planned by a software architect?
10. So Far, Enrollment Has Been a Disaster.The response to the initial delays was that people were so interested in signing up, they were crashing the servers. But if the servers can't handle a few hundred thousand people on the first day, what makes them believe they can handle the monstrous deluge when millions -- and possibly tens of millions -- of procrastinators try to sign up around Dec. 15? So, if anything, things may only get worse as we approach the deadline.
Despite all the problems, CostHelper is actually a fan of the concept of Obamacare. As a consumer information site, we're excited to see pre-existing conditions covered and assistance provided to people who will have difficulty paying for insurance, and we're hopeful that there is a program (in its beleaguered, early phases) to provide coverage for all Americans and to control long-term healthcare costs.
And these lessons aren't just for the rollout of the Affordable Care Act. Many of the critical issues this country faces, including immigration, data privacy, national security, and carbon emissions, will probably involve technology -- and more large-scale software projects -- to help solve them. It sounds like similar challenges all over again.
Let's just hope that next time, they talk to more software architects while they're working on the legislation. I hear engineers like pizza.
Ed Lee is the founder of CostHelper.com. He has worked in the technology industry for more than 15 years as a software engineer, manager, and founder, and graduated from Stanford University with degrees in Computer Science and Quantitative Economics.