The new Obamacare website, Healthcare.gov, officially opened on October 1, when it was immediately greeted by an onslaught on visitors that rendered the site unusable. Liberals trumpeted the millions of visitors as proof of Obamacare’s success (nevermind how many actually signed up or picked plans, as that was probably in the single digits). They attributed the early hiccups to the standard effects of really high traffic that would eventually be resolved.
But the Affordable Care Act site’s troubles run much deeper than just being coded too poorly to prevent empty drop-down menus or including too many javascript files on every page. My experience with the site so far indicates an embarrassingly rushed and incomplete product that I’m hesitant to trust with my personal information.
Only the government would decide to handle heavy traffic levels with a virtual waiting line! Though to be fair, an automatic queueing system is actually a fairly complex and impressive functionality for a website, and though I encountered it every time I visited it usually seemed to update to a log-in screen after a few minutes. But again, heavy traffic is the least of their problems.
The Username
I finally got to the sign-up page to create an account. On Step 2 I read the following:
Choose a username that is 6-74 characters long and must contain a lowercase or capital letter, a number, or one of these symbols _.@/-
It said to pick a username that used letters, numbers, or a handful of special characters. It did not say it required multiple combinations of those character types. So I typed in my alphanumeric name and promptly received an error:
OK, so maybe I need one of those special characters anyway. I added an underscore to the end of my name and the error went away. I finished the signup process, and… I received a generic error message that my account creation failed. I attributed the error to heavy traffic and tried again later, receiving the same error.
Later, I decided to try Internet Explorer instead of Firefox and also happened to try a different username, putting a period in the middle. This time, the account was created! I got a “Marketplace account created” email and clicked on the confirmation link. Later I saw that the “Trouble logging in?” page conveniently listed an additional username requirement:
So that’s why my first login attempts were failing! Not only does this page list a different character limit (minimum of 5 instead of 6) and specify that it can’t all be special characters, it also says that it can’t end in a special character (even PCI isn’t that picky). Remember, the sign-up validation let me through with one on the end even though it wouldn’t let me through without one at all!
This means that the text on the sign-up page, the front-end javascript validation on the sign-up page, and the text on the help page all have different requirements for valid usernames in the database! Eventually I stumbled on an acceptable name. But at least at that point, I proceeded to log in and check out my health insurance options, right?
Wrong.
The Password Reset
I tried to log in, and was told: “The information you entered isn’t valid. Review this information. If you’re having trouble, call the Marketplace Call Center…”
My login failure continued after several tries. OK, I thought, maybe I mistyped my password twice when I signed up, or maybe it’s still not connecting to the database due to high load. I headed to the “Forgot your password?” page to see if I could reset my password or at least confirm if my account had actually been created.
The page asked for my username and sent an email to my email address. This meant my account must actually exist in the database, since they were able to derive my email from my username! “Please click the link below to reset your password.” I clicked the link, and….
What?? Couldn’t find a profile? With the information I provided? You mean with the information you provided me from your own Marketplace?? I tried again three separate times over the next few days, at different times of day and from different browsers and operating systems. Each time I got an email, and each time the link in the email sent me to the error above. I even tried replacing the period in the username in the URL with its URI encoded value in case they weren’t escaping strings properly.
If heavy load was preventing connections to the database, how did it get the email from my username every time? But if it was connecting to the database fine, how did their self-generated Forgot Password link fail to match a profile every time? There must either be a bug in the link to the Forgot Password page or on the page itself.
What Else?
I tried the Live Chat option and got a helpful person after ten or fifteen minutes and explained my Forgot-Password-loop twice, but they basically just told me they were experiencing high traffic and to try again later, perhaps late at night or early in the morning.
The more I thought about these basic inconsistencies and bugs hampering every step of my progress, the more uneasy I became. These kinds of bugs reminded me of the kind of code I often find myself writing, especially when I haven’t taken the time to thoroughly debug, test for edge cases, or refactor things in a DRY manner.
And you know what else I tend to find in my code that has these kinds of bugs? Security holes. Lots of them. And when we hear about large systems getting broken into almost every other day, I shudder to think about what kinds of SQL injections or table name exposures are waiting to be discovered in code that seems to be this, well, sloppy. (It almost makes wonder if they’re even *gasp* hashing their passwords!) I feel bad for the poor souls forced to scrape this system together under who-knows-what constraints, but do I really want to trust my personal medical information to a treasure chest this big with such uncertain locks?
Sure, I’ve been biased against Obamacare from the start, and I’m half-surprised we’ve even made it this far. But I can’t say my interaction with it so far has done much to change my opinion – an interaction I’m only even mildly interested in because Mr. “If you like your insurance, you can keep it” Obama has already been wrong about both my and my wife’s previously offered plans.
I will admit I think the employer-insurance link is severely flawed (though arguably blamable on the government in the first place), and I even think increasing information and competition about plans can be a legitimate government function to improve market efficiency (i.e. the one part of Obamacare I actually almost sorta had a reason to hope for some kind of positive results).
Maybe the site will get better at handling the traffic levels. Maybe the little bugs will get fixed. Maybe the database connections don’t have any glaring holes. Maybe I did something stupidly wrong in my attempts above because I subconsciously didn’t want it work anyway and everybody else is having a better time. But if my experience thus far is any indication, we have not yet begun to debug.
Are you sure that government workers actually built this? I wouldn’t be surprised if this was done by contract, i. e. by a private business. If so, this is a classic example of the problem of “building to spec”. From a software engineering standpoint, building to spec can be a mess, and is frowned upon these days (so called, “agile programming” was created as an alternative development process). Even when you are talking about regular (non software) work, you are often better off hiring government workers instead of taking the low bid.
When I wrote of poor souls I was most certainly thinking of contractors who probably didn’t get enough time, feedback, etc. But who built it is somewhat irrelevant as I’m not looking for someone to blame; I simply view the result as an inevitable outcome of the sheer scope of attempted government intervention here – though I’m a little surprised at *how* bad some of the functionality is. Undoubtedly the site will improve over time, but likely at a greater cost and slower speed than originally advertised.
I don’t think it was inevitable that this was going to be bad. I think it could have been better. More importantly, since it is software we are talking about, it should get better, a lot better, over time. Unfortunately, depending on how similar decisions are made in the future, it might not.
I know software and I know a lot about the software development process, and if someone told me that this was a “contract to spec” project I could tell you from the beginning that it would probably be poor. Generally speaking, software development of this nature is a tough, time consuming business. I’ve done contract to spec work and it is full of potential problems. Simply coming up with a description of the problem is tricky. The low bidder may have lost money on the deal (or they took shortcuts, some of which are now visible). Again, that is why newer software development processes don’t involve that. It involves a process that is somewhat based on trial and error (along with a lot of user feedback). The key is to keep the software flexible (i. e. agile) so that you can change it as you better understand what it is the customer wants. But such a process won’t work if you have one organization making the contract (in this case the government) and another one building the product.
One extreme example of “Agile” processing is that used at Amazon. They routinely create different web pages for different people. The people randomly get assigned a specific look. Then the company gathers the data, and decides which one works best.
I know you wrote this to point out how bad this was. You claim this is because it was too big a task. I seriously doubt it. We aren’t talking about rocket science here. This is not as demanding as Amazon or Google (but more demanding than Facebook or Twitter). It is a midsize project, and they stumbled out of the blocks. It doesn’t help things that they were expected to “go live” and handle millions of requests (which is quite rare for any company — most start small and then grow). So, I’m not surprised they ran across problems with the traffic, but the problems with the web design are a different matter, and less excusable.
I think there are two possible reasons for this. One is exactly what I mentioned. Contracting is full of problems. Folks like it because it adds some free market to the mix. But as I said, sometimes you spend too much money spelling out the contract. In such cases (such as this) you are wasting your time (and our money). You are much better off hiring employees to do the job. The employees will learn the domain (in this case insurance) and do a better job. I can tell you that I’ve personally worked on a lot of websites (as a programmer) but if only given a couple months to throw this website together, I probably would have made many of the same mistakes. On the other hand, if I was hired as an employee within this organization, things would be different. After around six months I would have a good understanding of the software and the domain and be able to crank out something much better.
The other possible reason is that they just built it on the cheap. If these were government workers, but they were not well paid, nor well rewarded, nor enough of them, then they were likely to produce a poor product.
Generally speaking, when it comes to the government, you get what you pay for. The V. A. has what is routinely considered to be the best electronic patient record keeping system in the world . This is an extremely complex system (more complex than what this website is trying to do) but they nailed it, and nailed better than anyone else. Meanwhile, the V. A. struggles with the more basic task of getting former soldiers into the system. I can only guess that they simply didn’t budget for that (assuming, incorrectly, that we wouldn’t get involved in numerous unnecessary wars).
The user name doesn’t have to have symbols. Someone had already taken the user name you wanted, that’s why it was invalid.
That is a compelling theory that would fall under me doing something stupidly wrong, although I can’t test it right now as the site is down (hopefully to fix some of the problems I discovered above).
The only times I actually completed the sign up process and failed was when I was using a username with a symbol on the end, which passed the validation but broke a rule listed elsewhere. It’s possible (since I can’t check it right now) that the front-end javascript validation on the username step was actually AJAX requesting the database and presenting a generic “This is not a valid username” because the username was already taken, though I’m skeptical that such database-dependent functionality would have been working so consistently and quickly when the actual account creation was floundering so much – but again, it’s certainly possible.
Although, even if that was my problem, the system could have told me specifically that the symbol-less username was already taken, and not just invalid, since that is such a basic functionality of a website account system that you can easily find it working freely on any random open-source forum software that powers millions of sites.
After further testing, you are simply incorrect. I can input my username (which already exists) on the new account signup screen and get no invalid error on that step. Additionally, I can put in any string of letters (including many which almost certainly do not exist) and get an invalid error until I add either a symbol OR a number.
Are you sure that government workers actually built this? I wouldn’t be surprised if this was done by contract, i. e. by a private business. If so, this is a classic example of the problem of “building to spec”. From a software engineering standpoint, building to spec can be a mess, and is frowned upon these days (so called, “agile programming” was created as an alternative development process). Even when you are talking about regular (non software) work, you are often better off hiring government workers instead of taking the low bid.
When I wrote of poor souls I was most certainly thinking of contractors who probably didn’t get enough time, feedback, etc. But who built it is somewhat irrelevant as I’m not looking for someone to blame; I simply view the result as an inevitable outcome of the sheer scope of attempted government intervention here – though I’m a little surprised at *how* bad some of the functionality is. Undoubtedly the site will improve over time, but likely at a greater cost and slower speed than originally advertised.
I don’t think it was inevitable that this was going to be bad. I think it could have been better. More importantly, since it is software we are talking about, it should get better, a lot better, over time. Unfortunately, depending on how similar decisions are made in the future, it might not.
I know software and I know a lot about the software development process, and if someone told me that this was a “contract to spec” project I could tell you from the beginning that it would probably be poor. Generally speaking, software development of this nature is a tough, time consuming business. I’ve done contract to spec work and it is full of potential problems. Simply coming up with a description of the problem is tricky. The low bidder may have lost money on the deal (or they took shortcuts, some of which are now visible). Again, that is why newer software development processes don’t involve that. It involves a process that is somewhat based on trial and error (along with a lot of user feedback). The key is to keep the software flexible (i. e. agile) so that you can change it as you better understand what it is the customer wants. But such a process won’t work if you have one organization making the contract (in this case the government) and another one building the product.
One extreme example of “Agile” processing is that used at Amazon. They routinely create different web pages for different people. The people randomly get assigned a specific look. Then the company gathers the data, and decides which one works best.
I know you wrote this to point out how bad this was. You claim this is because it was too big a task. I seriously doubt it. We aren’t talking about rocket science here. This is not as demanding as Amazon or Google (but more demanding than Facebook or Twitter). It is a midsize project, and they stumbled out of the blocks. It doesn’t help things that they were expected to “go live” and handle millions of requests (which is quite rare for any company — most start small and then grow). So, I’m not surprised they ran across problems with the traffic, but the problems with the web design are a different matter, and less excusable.
I think there are two possible reasons for this. One is exactly what I mentioned. Contracting is full of problems. Folks like it because it adds some free market to the mix. But as I said, sometimes you spend too much money spelling out the contract. In such cases (such as this) you are wasting your time (and our money). You are much better off hiring employees to do the job. The employees will learn the domain (in this case insurance) and do a better job. I can tell you that I’ve personally worked on a lot of websites (as a programmer) but if only given a couple months to throw this website together, I probably would have made many of the same mistakes. On the other hand, if I was hired as an employee within this organization, things would be different. After around six months I would have a good understanding of the software and the domain and be able to crank out something much better.
The other possible reason is that they just built it on the cheap. If these were government workers, but they were not well paid, nor well rewarded, nor enough of them, then they were likely to produce a poor product.
Generally speaking, when it comes to the government, you get what you pay for. The V. A. has what is routinely considered to be the best electronic patient record keeping system in the world . This is an extremely complex system (more complex than what this website is trying to do) but they nailed it, and nailed better than anyone else. Meanwhile, the V. A. struggles with the more basic task of getting former soldiers into the system. I can only guess that they simply didn’t budget for that (assuming, incorrectly, that we wouldn’t get involved in numerous unnecessary wars).
The user name doesn’t have to have symbols. Someone had already taken the user name you wanted, that’s why it was invalid.
After further testing, you are simply incorrect. I can input my username (which already exists) on the new account signup screen and get no invalid error on that step. Additionally, I can put in any string of letters (including many which almost certainly do not exist) and get an invalid error until I add either a symbol OR a number.
That is a compelling theory that would fall under me doing something stupidly wrong, although I can’t test it right now as the site is down (hopefully to fix some of the problems I discovered above).
The only times I actually completed the sign up process and failed was when I was using a username with a symbol on the end, which passed the validation but broke a rule listed elsewhere. It’s possible (since I can’t check it right now) that the front-end javascript validation on the username step was actually AJAX requesting the database and presenting a generic “This is not a valid username” because the username was already taken, though I’m skeptical that such database-dependent functionality would have been working so consistently and quickly when the actual account creation was floundering so much – but again, it’s certainly possible.
Although, even if that was my problem, the system could have told me specifically that the symbol-less username was already taken, and not just invalid, since that is such a basic functionality of a website account system that you can easily find it working freely on any random open-source forum software that powers millions of sites.