Why Some State Health Exchanges Failed
October 05, 2013
With the launch of the Affordable Care Act’s online exchanges, some states are celebrating huge successes while others completely failed. We’ll explain why and how to avoid these mistakes when selecting a web development company.
Maryland was at the forefront of implementing the ACA. Gov. O’Malley established six policy workgroups and trained over 5,000 people to help consumers enroll. Their exchange site failed miserably with fewer than 100 people able to enroll before the site was taken offline.
Kentucky, meanwhile, had a cake with the number 100,000 written on it to celebrate passing that number of people who had prescreened for enrollment by Wednesday.
Colorado’s exchange, where we are located, has had problems with users experiencing outages and downtime, but nothing as severe as Maryland’s flat-faced failure. Still, it’s hard to imagine why the Colorado exchange’s homepage loads 1.1 MB of files and data!
All of these mistakes are amateur issues that a decision maker hiring a firm would never spot without addressing the issues covered in this post.
The Challenge of Selecting a Competent Tech Company
The recent launch of the federal and state exchanges has provided a phenomenal case study about the difficulty in selecting a truly competent web development firm.
Organizations looking to develop excellent web applications will benefit from understanding a few important concepts when vetting a development firm.
First, I’ll highlight three key points about web applications that are often overlooked. Then I’ll go into some recommendations about how you can address these points to ensure a better outcome.
Key Items for Application Development
- The visual appearance of a web page tells you nothing about how well the page is coded. Two pages could look identical to the human eye on screen, but one may be far lower quality. This can affect the expense of upgrading content and appearance in future versions, cross browser support issues, and most importantly performance and organic search.
- Examining the front-end code of a web application tells you nothing about how the backend software will perform under stress that comes with high volume use.
- Examining the back-end performance of a web application tells you nothing about how easy or difficult it will be to maintain and upgrade in the future.
Looking Beyond Basic Vetting
Every website project decision maker looks at basic qualifiers for a development vendor. The firm must be capable of designing an attractive, clean and functional website that looks professional and is easy to use. Then there is the importance of an established track record of successfully completing projects on time and on budget.
Once these two basic requirements are met, decision makers often start looking at the proposal costs. This is a huge mistake. Here’s why: An initial proposal from multiple firms is almost never apples to apples. There is no real map or formalized architecture at the time of an initial proposal.
Proposals often estimate radically different levels of application performance or features.
To use a car analogy, many firms attract business by quoting the site like they are building a Nissan Versa sedan, which costs under $13,000. The problem is that almost no one buys the cheapest cars. They simply don’t do what is needed. What’s more, web applications generate the big costs down the line in maintenance and future development.
What is the answer to this dilemma then? Never select a firm based on costs and content of an initial proposal. Instead, vet the firm based on communication skills, level of service and responsiveness, ability to deliver on time and on budget, a proper hourly billing rate, and most importantly a complete knowledge set about front end design (UI/UX) as well as back end engineering (code, databases and business intelligence).
Beyond the Basics: Addressing the Three Key Points
Ask your development firm about all of these issues during the vetting process. If their people can speak clearly, knowledgably and succinctly about these points, that is a good clue as to their skill and value. If they stumble and don’t provide specific examples of how they have worked with and addressed these types of challenges in past projects, it is a big red flag.
Point 1: Go Beyond the Visual Appearance
- Review the page to make sure that there are no <table> elements used unless the design actually calls for a data table (i.e. for pricing or product information).
- How many kilobytes are loading in the page code? Is the design overly complex with too many elements or is the source code clean, consistent and easy to read?
- Does the site use the most modern standards from HTML5 and CSS3? It should! But it should also still look good on older browsers too.
- Google, Bing and other search engines will read the code. More modern, well-designed, cleaner code will perform better for organic search rankings.
- Poorly architected code will be hard to maintain and update. It is difficult for a content manager to work with. Poorly architected code also makes it hard for universal CSS changes that keep the site looking fresh and modern.
Point 2: Stress Test a Serious Site & Be Ready to Scale Up
If designing a small business “mom and pop” application, stress testing doesn’t matter. But if you are designing a shopping cart that will end up with high volume in the future or high stress periods such as during sales or holiday shopping periods, stress testing is critical during development before the big launch.
- What is the strategy for stress testing the site and discovering bottlenecks before “go live”?
- Is the firm going to use third party software to simulate a range of expected traffic?
- Will the load testing account for hacker attacks such as DDOS attacks (distributes denial of service attacks)?
- What is the strategy for adding more support as volume increases?
- What will the costs be to expand capacity?
- How rapidly can these resources be added?
- Can the resources be reduced during slow periods and increased elastically during high volume periods to save costs?
Point 3: How Architecturally Sound Is Your App?
Ask the question: If and when changes and upgrades are needed, how easy will it be to implement them? A well-architected application is modular so that different components can be upgraded without impacting other areas. A poorly architected application has code that is deeply entwined and makes it difficult to change.
- Determine how the firm will trap, record and report on exceptions and errors.
- Ask how the various elements of the application will be separated to ensure that other developers can work independently on different areas.
- Will the firm use interface based design practices?
- Will late model binding and inversion of control (IOC) methods be employed so that business logic and data management components can be re-optimized or redeveloped later to upgrade or enhance performance and capacity?
- Most importantly, does the firm know these terms and understand why or why not to implement these development patterns for a specific project?