This munificent attitude has not yet been extended to the developers of healthcare.gov or the ACA (the Affordable Care Act) or, as it is best known, Obamacare. Most especially the techie part of it.
Despite our shrugging acceptance of the glitches, bugs, frustrations and general incomprehensibility that we seem to regard as a matter of course when it comes to new computers, smartphones, tablets and all of the impedimenta that comes with them, such emotional largesse has not been to anyone or anything associated with the rollout of the largest US public policy initiative since Medicare.
This acceptance of inscrutability and indifference from the private sector but not from the public bears understanding. But perhaps more importantly, it suggests that we are only just beginning to understand the complexity that accompanies the launch of any new product or service with a technological component - which is to say, anything we attempt these days.
The questions raised, as the following article explains, shed light on how technology affects so many aspects of our lives, how little we understand of it - despite our surrender to it of myriad features, functions, controls and rights - and how that must - and probably will - now change. We share the view that the more transparency a subject receives, the better it is likely to be - and the sooner, too. But just as we have had to endure moments of discomfort as the true nature of the food we eat is revealed, so we may find that the more we learn about technology, the less we may be willing to simply accept it. JL
Lorinda Brandon comments in SmartBear:
The website problems that plagued the rollout of Obamacare shoved the topic of software testing into the mainstream conversation.
If you’re anything like me, you’ve spent most of your adult life having your family members describe your career as “something in software.” I’ve been introduced to many people with a plastic smile on my face while my relatives say, “This is Lorinda. She does something in software.” And that’s fine – despite being surrounded by software and professionals who build it, the reality of how software is built is still a mystery to most people.
I’ve found that some concepts are easier for people to grasp: When I was a program manager, it seemed to make sense to non-techies because there are program managers in just about every industry. And I suppose if I were a developer, it would make sense to people too (based on what they’ve heard about basement-dwelling Red Bull addicts).
But when I tell them I am a software tester or that I’m manage a testing team, I can see them trying to translate what they know of testing (banging car doors or putting test tubes in a centrifuge) to software. Imagine then trying to explain that I used to do those things and now I am a Software Quality Evangelist… ah, the blank stares.
At least, until recently.
While several “software glitches” have been featured on the evening news, I can’t recall any that have caused a national conversation about the process of building and testing software unti Healthcare.gov. Suddenly, Americans are sitting at their kitchen tables – in suburbs, in cities, on farms – and talking about quality issues with a website.
The average American was given nightly tutorials on load testing and performance bottlenecks when the site first launched, then crumbled moments later. We talked about whether the requirements were well-defined and the project schedule reasonably laid out. We talked about who owns the decision to launch and whether they were keeping appropriate track of milestones and iterations. After that came the public discussions about security holes, which, admittedly, is not an unfamiliar concept to most people.
But with those discussions came a healthy dose of encrypted passwords, third-party information sharing, and authentication protocols. School children and grandparents alike are now worrying about whether their passwords are being passed in the clear now. Imagine that. There was even a major congressional hearing about the site, much of which focused on whether it was tested well enough.
When the media went from talking about the issues in the website to the process used to build the website was when things really got interesting. This is when software testers stepped out of the cube farm behind the coffee station and into the public limelight. Who were these people – and were they incompetent or mistreated? Did the project leaders not allocate enough time for testing? Did they allocate time for testing but not time to react to the testing outcome? Did the testers run inadequate tests? Were there not enough testers? Did they not speak up about the issues? If they did, were they not forceful enough?
Then there was the grassroots movement – testers and developers around the country performing their own tests and doing their own code reviews and releasing fixes after the code was released to GitHub. Testers like Ben Simo got their 15 minutes of fame because they devoted their own personal time to testing the site and blogged about the issues they found. Now the average Americans not only learned what we do for a living but what we’re made of – this is not a 9-to-5 job. This is a lifestyle; this is a belief system; this is just how we tick.
And, while tempers flared and accusations were flung about, I couldn’t help sitting off to the side and gloating a little, because finally, my family understands what I have spent my career doing … and perhaps also the people they introduce me to.
0 comments:
Post a Comment