Brown M&Ms from Van Halen on Vimeo.
Van Halen had an infamous rider in their contracts with promoters during the 80’s when they were touring the nation non-stop - no brown M&M’s backstage. A lot has been made of rock star excess with regard to their contract riders. A photographer named Henry Hargreaves even created still life’s of the more audacious ones.
Diamond Dave does a good job of explaining just why Van Halen put such an odd demand in their contract. They were attempting something new with their huge stage setup and most promoters across the US weren’t prepared for this massive stage. Some promoters didn’t even bother to read the rider. Van Halen knew this, and they also knew that in order to be safe, their promoters needed to follow their advice on stage setup to the letter. Placing an odd clause in the middle of the rider was an early flag on knowing that their stage was set up properly. Say what you will about Van Halen’s rock n’ roll excesses, but the men were professionals.
Healthcare.gov was attempting to build an entirely new system. One that was arguably larger and more complex than anything that had been attempted before. Documenting that process (which I’m sure they did) should have included some brown M&M’s - so what does that mean?
Code errors and deficiencies
And regardless of whether or not the site was ready functionally, you do not go to production without having cleaned up the code to some degree. They were missing some processes that could have cleaned up their code and would have at least launched a website that might have been functionally deficient, but not embarrassingly untested - each glaring error is just piling one on top of the other now.
Building in Brown M&M’s
Web Development is about getting things to work in the browser, but in the midst of that process, you have to have some standards to fall back on, some checks in the process to ensure that what you’ve built doesn’t just work, but is maintainable going forward and offers a reasonable experience to anyone who visits the site, regardless of the technology they might be using - phone, tablet, or Windows PC running Internet Explorer 6.
One way the development teams I’ve worked on building broadly supported websites is to validate our code against W3C standards. Here’s the thing about validation - it isn’t 100% necessary. No one who looks at a website via a browser will know for certain that the website meets W3C standards by looking at it. The website will still work, the images will still display, the data you submit will still go to the server.
You have to test for it. It’s a test that takes you out of the normal workflow of development. It slows you down. To me, that’s the point. It’s a brown M&M - something that you put there to make sure you have done all the other things you are supposed to do to build a complex website. As I’ve transitioned from in the trenches developer, to tech lead and architect, I’ve used validation as a way of ensuring that other members of the team are accountable to that standard too. Validation lets me know that they’ve done the cleanup - they’ve verified their work independently and are ready to push their code to production. In cases where code doesn’t 100% validate, they have answers for why. Sometimes, that code gets pushed to production anyhow, because we know why that error is there and we know it won’t affect the site. Other times, it requires us to fix and rewrite code to meet that standard. But we test and verify the solution, every time.
Healthcare.gov could have used some brown M&M’s in their documentation
Validation and Testing are a process that give cover to engineers and managers alike. It sounds like the pressure on the healthcare.gov team was extreme - but that’s no excuse for pushing a site live that hasn’t been properly tested and validated. Documenting and detailing those requirements up front - in the planning stages, before coding even begins, ensures that those proverbial brown M&M’s aren’t left in the catering area - evidence that the system wasn’t built to all of the required specifications.
Lack of valid HTML code didn’t cause healthcare.gov to fail. It could have run just fine with or without that W3C seal of approval, but a lack of sufficient testing and validation surely contributed to the downfall of the site on launch day. There were brown M&M’s all over that website.