Cigar
11-13-2013, 02:09 PM
Meet the DeBuggers -- An attitude adjustment regarding the "Fix" at Healthcare.gov (http://www.dailykos.com/story/2013/11/12/1254621/-Meet-the-DeBuggers-An-attitude-adjustment-regarding-the-Fix-at-Healthcare-gov)
Let me start off by saying that Healthcare.gov is working well in most areas of the US. Folks are accessing the site all day, every day, and getting enrolled. Current capacity is up to 17,000 enrollments per hour. As of Oct. 25, about 700,000 U.S. residents have completed applications for health insurance, but many of those applications still need to be processed. About half of those applications have come through HealthCare.gov, and about half through the state-run insurance exchanges.
At the same time, backstage, a "Tech Surge" team has been deployed to fix specific bugs that certain users encounter, and to streamline the User Experience (http://apmblog.compuware.com/2013/10/22/diagnosing-obamacare-website-performance-issues-with-apm-tools/?utm_content=buffer49a52&utm_source=buffer&utm_medium=twitter&utm_campaign=Buffer) so that it is friendly and fast.
On launch day, October 1, 2013, there were three main problem areas that emerged:
1. The User Interface: This includes site navigation, enhanced and friendlier error messages, and code and script consolidation -- which means speeding up the process.
2. Database Integration: The process of online enrollment requires Healthcare.gov to look up user info in dozens of third-party databases, both public and private. Each looh up requires a very specific handshake so that information can be exchanged. Sometimes a simple typo, an empty field, or random punctuation can cause a serious bug that stops the process cold. This is true in all releases of huge integrated systems and it is normal for these bugs to be fixed on the fly after release. If you've ever used a computer with an operating system, then you are familiar with this ongoing process.
3. Project Management: In the last month or so before the October release, it appears that there was no one integrating and optimizing the work of all the teams completing different parts of the program into one seamless, streamlined process. The early source code tells that story. Much of this was quickly rectified, the rest is being ironed out, and the person who dropped the ball on systems integration has stepped down.
(http://www.washingtonpost.com/blogs/wonkblog/wp/2013/11/06/healthcare-govs-head-tech-guy-is-out/)
I'll give you my perspective on Healthcare.gov post-launch tech surge -- but, first, I'd like to repeat what you already know: The mad-dog political hysteria going on in congressional hearings and derp-news are nothing more than a continuation of the attempt to kill the PPACA. It is noise.
The Surge Team will meet and perhaps even beat the deadline, as Healthcare.gov improves hourly. There is absolutely no need to fret over this.
As a result of the buggy rollout of Healthcare.gov, where the servers were swamped and certain database verifications froze for certain users, losing their data -- the Obama administration responded with a firm commitment to speedily fix the problems. A “tech surge” for HealthCare.gov was announced on October 22, which would be completed while the site is up and running and enrollments continue. A cadre of engineers and programmers from America's smartest tech giants have jumped on board to help fix technical issues troubling HealthCare.gov. Google, Red Hat, and Oracle are among the elite participants.
::
Like quite a few here, I've worked on software deadlines -- and worked on the crunches to fix the inevitable glitches that often can only be found in real time. When you work on a 'round-the-clock team, you actually spend a lot of time alone between brief "project update meetings." Depending on your expertise, you are analyzing, fixing, patching, or bit-diddling. Time means nothing. You just keep going until the next meeting.
On my teams, I was one of the "flat food" types. I kept my door closed. Sometimes friends would drop off food that could be slid under the door. That meant my diet consisted of things like pizza, cookies, and the occasional tostada. Other members on the team worked with open doors and some would periodically meet in the whiteboard lounge for brief collaborations. Project monitoring took place via messaging. Phone conversations were rare. So was paper. No one had a life until the job was done.
I don't know for certain, but I imagine that's pretty much what it looks like over at Healthcare.gov.
Let me start off by saying that Healthcare.gov is working well in most areas of the US. Folks are accessing the site all day, every day, and getting enrolled. Current capacity is up to 17,000 enrollments per hour. As of Oct. 25, about 700,000 U.S. residents have completed applications for health insurance, but many of those applications still need to be processed. About half of those applications have come through HealthCare.gov, and about half through the state-run insurance exchanges.
At the same time, backstage, a "Tech Surge" team has been deployed to fix specific bugs that certain users encounter, and to streamline the User Experience (http://apmblog.compuware.com/2013/10/22/diagnosing-obamacare-website-performance-issues-with-apm-tools/?utm_content=buffer49a52&utm_source=buffer&utm_medium=twitter&utm_campaign=Buffer) so that it is friendly and fast.
On launch day, October 1, 2013, there were three main problem areas that emerged:
1. The User Interface: This includes site navigation, enhanced and friendlier error messages, and code and script consolidation -- which means speeding up the process.
2. Database Integration: The process of online enrollment requires Healthcare.gov to look up user info in dozens of third-party databases, both public and private. Each looh up requires a very specific handshake so that information can be exchanged. Sometimes a simple typo, an empty field, or random punctuation can cause a serious bug that stops the process cold. This is true in all releases of huge integrated systems and it is normal for these bugs to be fixed on the fly after release. If you've ever used a computer with an operating system, then you are familiar with this ongoing process.
3. Project Management: In the last month or so before the October release, it appears that there was no one integrating and optimizing the work of all the teams completing different parts of the program into one seamless, streamlined process. The early source code tells that story. Much of this was quickly rectified, the rest is being ironed out, and the person who dropped the ball on systems integration has stepped down.
(http://www.washingtonpost.com/blogs/wonkblog/wp/2013/11/06/healthcare-govs-head-tech-guy-is-out/)
I'll give you my perspective on Healthcare.gov post-launch tech surge -- but, first, I'd like to repeat what you already know: The mad-dog political hysteria going on in congressional hearings and derp-news are nothing more than a continuation of the attempt to kill the PPACA. It is noise.
The Surge Team will meet and perhaps even beat the deadline, as Healthcare.gov improves hourly. There is absolutely no need to fret over this.
As a result of the buggy rollout of Healthcare.gov, where the servers were swamped and certain database verifications froze for certain users, losing their data -- the Obama administration responded with a firm commitment to speedily fix the problems. A “tech surge” for HealthCare.gov was announced on October 22, which would be completed while the site is up and running and enrollments continue. A cadre of engineers and programmers from America's smartest tech giants have jumped on board to help fix technical issues troubling HealthCare.gov. Google, Red Hat, and Oracle are among the elite participants.
::
Like quite a few here, I've worked on software deadlines -- and worked on the crunches to fix the inevitable glitches that often can only be found in real time. When you work on a 'round-the-clock team, you actually spend a lot of time alone between brief "project update meetings." Depending on your expertise, you are analyzing, fixing, patching, or bit-diddling. Time means nothing. You just keep going until the next meeting.
On my teams, I was one of the "flat food" types. I kept my door closed. Sometimes friends would drop off food that could be slid under the door. That meant my diet consisted of things like pizza, cookies, and the occasional tostada. Other members on the team worked with open doors and some would periodically meet in the whiteboard lounge for brief collaborations. Project monitoring took place via messaging. Phone conversations were rare. So was paper. No one had a life until the job was done.
I don't know for certain, but I imagine that's pretty much what it looks like over at Healthcare.gov.