Ajouter un commentaire

Don’t Let Your Best Day Be Your Worst Day

The launch of healthcare.gov has brought a tidal wave of criticism. Some say the code was buggy, others blame the servers, and still others blame the user experience. While we may not be able to pinpoint exactly what went wrong in this build, one thing is certain: What should have been a great day for many Americans became the worst day for the technology providers behind healthcare.gov.

In the past week, I’ve been asked a few times if the site is built in Drupal (no), if Acquia was involved (no), and what could have been done to avoid this situation.

The latter question is one that requires more than a technology consideration.

When we look at technology projects only in terms of code and hardware, we are setting ourselves up for failure. Technology projects should support the people, the projects, and the objectives of the mission they are being built to support. For too long in the public sector, we have seen technology projects fail not because of the technology itself, but for the following factors:

  • Not focusing on performance first. Part of having a usable site is…having a site that can be used. Performance may not be the sexiest part of a technology project, but it’s the most important. When a prospective or current client tells me “that stuff isn’t important” I see that as a key education opportunity. It’s not the time to say “the customer is always right”. It’s the time to fight for the integrity of the application.
  • Vendor selection: This is a key pain point in public sector. Procurement requirements and the evaluation process for public sector bids can eliminate the most qualified technical providers. Contracting officers select a “safe choice” from a procurement standpoint. This choice is oftentimes not the most strategic technical or management selection for the project.
  • Outdated management methodologies: Strict fixed price, fixed scope contracting models force a rigid approach that doesn’t work well for software development. Matching the management approach with a contract model that works well for software development is critical. That work has to be done far in advance.
  • Cramming in scope: When teams try to fit too much in, or please everybody, they more often than not end up developing a product that meets nobody’s needs and doesn’t perform well.
  • Believing that an “iterative” approach means testing isn’t necessary. This is a major pitfall with a lot of technology projects I’ve come across. Testing is always important, and testing should be done iteratively and thoroughly. When budgets are tight, performance and load testing are often the first line items to go.
  • Testing when it’s too late. Many teams delay testing on their site until the final stages, right before launch. While I applaud their commitment to testing, if there isn’t time to improve, the site will still suffer.
  • Selecting the right technology for the job. While I would love to say Drupal is the best solution all the time, what I care about more is Drupal being successful all the time. At Acquia, we honestly advise to use the right technology for the job, regardless of what’s new, what we support, or what makes us money. This is especially important for those of us working in public sector. We have an obligation to provide the best solution for not only our clients, but taxpayers as well.
  • Don’t reinvent the wheel. Well-architected sites fail because the hosting environment wasn’t properly sized or built to handle the load. Clients looking to host a high-traffic, mission-critical site like healthcare.gov should identify existing, tested, and easily scalable solutions. Less time focusing on infrastructure leaves more time to focus on building (and thoroughly testing) the application layer - which is truly the sexy part end users will care about.

From the information released on the healthcare.gov launch, it’s hard to know what went wrong. While I can’t say for sure if some or all of the above factors contributed to the release of healthcare.gov and we certainly can’t say that Drupal would have solved this. I do know that big projects need to be done right. The right team needs to be involved, the right management approach implemented, and the right technology selected and tested.

Plain text

  • Aucune balise HTML autorisée.
  • Les adresses de pages web et de courriels sont transformées en liens automatiquement.
  • Les lignes et les paragraphes vont à la ligne automatiquement.

Filtered HTML

  • Use [acphone_sales], [acphone_sales_text], [acphone_support], [acphone_international], [acphone_devcloud], [acphone_extra1] and [acphone_extra2] as placeholders for Acquia phone numbers. Add class "acquia-phones-link" to wrapper element to make number a link.
  • Pour publier des morceaux de code, entourez-les avec les balises <code>...</code>. Pour du PHP, utilisez. <?php ... ?>, ce qui va colorier le code en fonction de sa syntaxe.
  • Les adresses de pages web et de courriels sont transformées en liens automatiquement.
  • Tags HTML autorisés : <a> <em> <strong> <cite> <blockquote> <code> <ul> <ol> <li> <h4> <h5> <h2> <img>
  • Les lignes et les paragraphes vont à la ligne automatiquement.
By submitting this form, you accept the Mollom privacy policy.