Build It and They Will Come - Worthy Repeat
Or, should I title this "The Importance of Testing"?
The failure of the Obamacare computer system to function has been a media highlight since its clumsy launch date. Every few days, we learn even more about the money spent and problems to fix.
There are so many lines of older (not cutting edge) code written, IT gurus have been brought in to read it line by line and make corrections. They have found Beta test code still in there taking up space. That is like saying after the surgery, "doc my tummy hurts" only to find - sorry - they left a towel in there when they sewed you back up. Not only are they bringing in more guys to fix it, they are keeping the originals to work alongside them.
The contract to develop America's most notable software for the most important presidentially sponsored mandate in her history was quietly awarded to a Canadian company. At a time when our country was still reeling/ recovering from the worst recession since 1929, jobs were given to people in another country. Not only that, the "final" cost was three times the initial bid. I have heard of overages, but none so high that are not fiercely tackled by the corner office. This gluttony has been treated like the swipe of your finger on an iPad screen. Oh wait - that's another American company that could have been consulted.
Do you think that all the fixes necessary are being done for free? I've heard that IT is on this 24/7. Hmmm. Ever heard of over time? This cost overrun is spiraling out of control and the system still doesn't work. Recently, the cabinet secretary overseeing Obamacare denied that she should be fired because she doesn't work for the American people. Later, she scrambled to reframe that comment. Why not fire from the top down? Isn't that where the final approval comes from? When the top person makes the big oops, shouldn't they go? Usually, they do. Unless it's a political position.
It all boils down to a dirty little programming secret engineers know about the software development lifecycle: this was rushed out the door without the proper testing. The entire Quality Assurance phase was skipped in part or in whole. QA for short.
I know about this tug of war because one of the hats I once wore was in project management in software development. I had to get the time frame estimates from programming, QA and documentation in order to provide our CEO with project completion dates. When he didn't like the final release date and pounded on the table, each department had to determine where to shave time. Where do you think it came from? Right after documentation (hey, that stuff can be mailed later) QA was hit the hardest.
QA engineers are programmers in reverse. Their job is to take the code and try to break it. When they find errors, they ship it back to the programmers to nip and tuck. This goes back and forth on projects of every scope and size. When the testers believe it is client-worthy the code is released. Industry insiders will often joke that the final release was "beta" and "don't worry, the clients are doing the QA for this one." Meaning: the QA department was not given the time to do their job, and in order to please the client the code was delivered. When this happens, the QA department spends post-release time working with the frustrated client who discovers some of the untested errors. Other projects get pushed back as this hamster wheel continues to whirl. At the very least, it is embarrassing for the developers and depending on the client, could cost them future business.
When I worked in software development, the company decided to create a new product and spent 3 years using their perceived best, brightest and newest hires. As project coordinator, I was in on all the time-flow meetings but not the development ones. After 36 months (just prior to the balloon fan fare and new polo shirts accompanying this new product launch) I was sitting in the usual project meeting when I learned a horrible truth. The new product had been entirely developed without any research about the intended users.
I couldn't believe little ol' me had just realized such a glaring oversight and politely framed a question to the effect "you mean we just spent over two years and how many millions developing something for an end user that has never been consulted?" I wondered how we knew just what the users would want and how they would use our system. The CEO's answer was loud and clear as he chuckled, "We will build it and they will come." Everyone around the board table laughed heartily while I struggled not to let my jaw hit the table. Fast forward 6 months. The product bombed, 52 people were laid off and the leader of the pack had to leave the organization. Several million dollars were pridefully wasted. It all could have been prevented with some initial research.
The Obamacare designers would have been wise to consult some successful internet site developers like Amazon, Google and Facebook to name a few. After 3 years promoting this very big deal, they were not prepared for a ton of interest on day one.
I wish I could say only a few million had been lost with the Obama fiasco. I shudder to think the number is so much higher and that way more than 52 jobs have been impacted. And just think, once this thing is fixed the same type of approach will focus on the private medical records of everyone. People untrained and lacking the skills that already exist in the private sector will now be determining our health care. The unimaginable is becoming reality. Outrageous.
America, wake up. There is no software fairy. Ideas need to be vetted and gulp, once in development you can't skip the testing phase if the desired outcome is a working product. Intentionally ignoring QA is like setting up a picnic on railroad tracks and get angry when trains approach.
Wait. Was this colossal failure intentional after all? After all, it is so big and in-your-face it's ridiculous. Oh no. Is this the Pelican Brief IRL? Hide me now.
The failure of the Obamacare computer system to function has been a media highlight since its clumsy launch date. Every few days, we learn even more about the money spent and problems to fix.
There are so many lines of older (not cutting edge) code written, IT gurus have been brought in to read it line by line and make corrections. They have found Beta test code still in there taking up space. That is like saying after the surgery, "doc my tummy hurts" only to find - sorry - they left a towel in there when they sewed you back up. Not only are they bringing in more guys to fix it, they are keeping the originals to work alongside them.
The contract to develop America's most notable software for the most important presidentially sponsored mandate in her history was quietly awarded to a Canadian company. At a time when our country was still reeling/ recovering from the worst recession since 1929, jobs were given to people in another country. Not only that, the "final" cost was three times the initial bid. I have heard of overages, but none so high that are not fiercely tackled by the corner office. This gluttony has been treated like the swipe of your finger on an iPad screen. Oh wait - that's another American company that could have been consulted.
Do you think that all the fixes necessary are being done for free? I've heard that IT is on this 24/7. Hmmm. Ever heard of over time? This cost overrun is spiraling out of control and the system still doesn't work. Recently, the cabinet secretary overseeing Obamacare denied that she should be fired because she doesn't work for the American people. Later, she scrambled to reframe that comment. Why not fire from the top down? Isn't that where the final approval comes from? When the top person makes the big oops, shouldn't they go? Usually, they do. Unless it's a political position.
It all boils down to a dirty little programming secret engineers know about the software development lifecycle: this was rushed out the door without the proper testing. The entire Quality Assurance phase was skipped in part or in whole. QA for short.
I know about this tug of war because one of the hats I once wore was in project management in software development. I had to get the time frame estimates from programming, QA and documentation in order to provide our CEO with project completion dates. When he didn't like the final release date and pounded on the table, each department had to determine where to shave time. Where do you think it came from? Right after documentation (hey, that stuff can be mailed later) QA was hit the hardest.
QA engineers are programmers in reverse. Their job is to take the code and try to break it. When they find errors, they ship it back to the programmers to nip and tuck. This goes back and forth on projects of every scope and size. When the testers believe it is client-worthy the code is released. Industry insiders will often joke that the final release was "beta" and "don't worry, the clients are doing the QA for this one." Meaning: the QA department was not given the time to do their job, and in order to please the client the code was delivered. When this happens, the QA department spends post-release time working with the frustrated client who discovers some of the untested errors. Other projects get pushed back as this hamster wheel continues to whirl. At the very least, it is embarrassing for the developers and depending on the client, could cost them future business.
When I worked in software development, the company decided to create a new product and spent 3 years using their perceived best, brightest and newest hires. As project coordinator, I was in on all the time-flow meetings but not the development ones. After 36 months (just prior to the balloon fan fare and new polo shirts accompanying this new product launch) I was sitting in the usual project meeting when I learned a horrible truth. The new product had been entirely developed without any research about the intended users.
I couldn't believe little ol' me had just realized such a glaring oversight and politely framed a question to the effect "you mean we just spent over two years and how many millions developing something for an end user that has never been consulted?" I wondered how we knew just what the users would want and how they would use our system. The CEO's answer was loud and clear as he chuckled, "We will build it and they will come." Everyone around the board table laughed heartily while I struggled not to let my jaw hit the table. Fast forward 6 months. The product bombed, 52 people were laid off and the leader of the pack had to leave the organization. Several million dollars were pridefully wasted. It all could have been prevented with some initial research.
The Obamacare designers would have been wise to consult some successful internet site developers like Amazon, Google and Facebook to name a few. After 3 years promoting this very big deal, they were not prepared for a ton of interest on day one.
I wish I could say only a few million had been lost with the Obama fiasco. I shudder to think the number is so much higher and that way more than 52 jobs have been impacted. And just think, once this thing is fixed the same type of approach will focus on the private medical records of everyone. People untrained and lacking the skills that already exist in the private sector will now be determining our health care. The unimaginable is becoming reality. Outrageous.
America, wake up. There is no software fairy. Ideas need to be vetted and gulp, once in development you can't skip the testing phase if the desired outcome is a working product. Intentionally ignoring QA is like setting up a picnic on railroad tracks and get angry when trains approach.
Wait. Was this colossal failure intentional after all? After all, it is so big and in-your-face it's ridiculous. Oh no. Is this the Pelican Brief IRL? Hide me now.
Comments
Post a Comment