Technology Nor Technologist at Fault
Webprofessionals.org has a keen interest in following the aftermath of the HealthCare.gov debacle. Why? For starters, as a professional association for Web professionals and those that teach, we’ve been advocating the adoption of Web project management best practices for over 17 years.
Our coverage on the topic over the years has included examining why most IT projects fail. More importantly, our number one goal is to educate Web professionals about what best practices actually means and how Web project management differentiates from traditional project management. Additionally, we aim to provide you with resources that can help you to avoid some of the more common sand traps along the way.
The HealthCare.gov debacle for example, is a classic case study of what happens to Web projects large and small when some of the most fundamental rules of best practices are not adhered too. Sadly, in this case the technology and the technologist often get caught in the crossfire. The risk for the Web professional includes being laid off, fired or blamed for the failure of the project.
For today’s podcast, I’ll share what others are saying and have written about the HealthCare.gov topic. I’ve also included a brief interview with Tonya Price, WebProfessionals.org Executive Committee member Web Project Management instructor for Webprofessionals.org about the importance of understanding Web project management..
New York Times – Red Flags Early on
According to the New York Times article printed October 13, 2103, the $400 million plus HealthCare.gov portal had red flags from the start. The also article reports that the trouble started when the U.S. government gained control of the 55 contractor project while those close to the project expressed skepticism. For example, in 2011 an internal progress report identified a lack of employees “to manage the multiple activities and happening concurrently as a “major risk” to the whole project.
Associated Press – Coders Who Built the Obamacare Website Knew It Had Huge Problems
The Associated Press article posted the BusinessInsider.com writes that, “as questions mount over the website’s failure, insider interviews and a review of technical specifications by The Associated Press found a mind-numbingly complex system put together by harried programmers who pushed out a final product that congressional investigators said was tested by the government and not private developers with more expertise.”
Project developers who spoke to the AP on condition of anonymity — because they feared they would otherwise be fired — said they raised doubts among themselves whether the website could be ready in time. They complained openly to each other about what they considered tight and unrealistic deadlines. One was nearly brought to tears over the stress of finishing on time, one developer said. Website builders saw red flags for months. Read more by clicking here.
Bloomberg Business Week – The Obamacare Website Didn’t Have to Fail. How to Do Better Next Time
This article reports that Companies such as Google, Amazon.com, Twitter, and Facebook all think in terms of platforms talking to applications. They deploy lots of small teams that are expected to ship new features and fixes all the time—sometimes daily. Like anything that involves human beings, shipping code can devolve into squabbling, missed deadlines, and flawed releases. The programming community’s key realization is that the solution to these problems is to create more transparency, not less: code reviews, tons of “unit tests” to automatically find flaws, scheduled stand-up meetings, and the constant pushing of new code into the open, where it’s used by real people. To cite just one example, developers at the giant online marketplace Etsy are encouraged to release code to the world on their first day of work. Government IT can’t work in such a transparent way. Or could it? There’s a whole set of tools, methods, and processes already set up and ready to use, all embodied in the culture of open-source software development. The U.S. federal government, led by the executive branch, should make all taxpayer-funded software development open-sourced by default. In the short run, this would help to prevent the recurrence of problems like those that plague healthcare.gov. Longer term, it will lead to better, more secure software and could allow the government to deliver a range of services more effectively. And it would enrich democracy to boot.
The article continues to state that the basic goal of the free software movement is to make useful software code available to anyone who wants it. Thirty years ago this sounded like communism, because code was seen as a kind of property. But in recent decades many people have come to believe that software code is more like a conversation. (As one famous programming textbook put it, “Programs must be written for people to read, and only incidentally for machines to execute.”) That’s why people say that free software is free as in free speech, not as in beer.
Want to open-source code? Choose a free software license and release your code online with the text of that license attached. That’s all it takes. History shows, however, that just licensing code and making it available isn’t enough. You need to create a culture around your project and engage with other people doing related work. If you do a good job of it, you and your collaborators can create great, first-class, highly secure software. Web browsers such as Mozilla Firefox and Google Chrome were built this way. It’s very likely that the smartphone in your pocket is built on top of an open-source kernel. http://mobile.businessweek.com/articles/2013-10-16/open-source-everything-the-moral-of-the-healthcare-dot-gov-debacle
The government has an advantage over typical open-source projects. People, including programmers, are intrinsically interested in what it’s doing, often because their lives are affected directly. If it wanted to, the U.S. could tap an army of interested coders ready to support official efforts.
The Weekly Standard – Obamacare sites pirated copyrighted web scripts
The article published by trhe RT network quoted the Weekly Standard as saying that the “main “Obamacare” website has been marred with bugs and glitches since it went online over two weeks ago, and the problems are still piling up. Now according to The Weekly Standard, the Department of Health and Human Services could be sued by the British developers who coded part of the site but were never credited.”
According to the report, Standard reporter Jeryl Bier noted on Thursday that one of the scripts used in powering Healthcare.gov is called DataTables, and it was released by a British company called SpryMedia on condition that anyone who utilized the open-source software provide proper attribution.
“DataTables is free, open source software that you can download and use for whatever purpose you wish, on any and as many sites you want,” Bier quotes from SpryMedia’s website. “It is free for you to use! DataTables is available under two licenses: GPS v2 license or a BSD (3-point) license, with which you must comply (to do this, basically keep the copyright notices in the software).” HHS, apparently, didn’t read that memo and now might end up in hot water. Bier has provided a number of examples showing how the Obama administration essentially pilfered the code piece-by-piece, except for the attribution that its developers insisted be included. The Standard said a representative for SpryMedia said they were “extremely disappointed” to hear about the misuse and would be pursuing the matter further with HHS. According to Bier, the company could pursue legal action over the unauthorized use of its copyrighted web script.
AssociationsNow- Failure to Launch: How to Avoid Your Own Website Debacle
From HealthCare.gov to the Common Application website, it’s been a rough few weeks on the internet. Two web-development experts discuss what went wrong, and how associations can avoid a similar fate. Nothing will get an organization in hot water with the public—and maybe even Congress—quicker than having a website that doesn’t work. Click here for full story.
Interview with Tonya Price, WebProfessionals.org Executive Committee Member and Web Project Management Instructor for the Web Project Management Course offerd by WebProfessionals.org