<div dir="ltr">I agree Bill. I am willing to bet $100 once we know the background story to this project's problems that (a) how it was managed was the root cause of all that happened--project management and (b) that while some technical issues were probably present, such as linking to preexisting databases and bad code writing, that they were outgrowths of the first.<div>
<br></div><div>The Federal Government has a long history of difficulties in delivering large high profile projects, and often for reasonable reasons. They rarely get studied by historians, however, as I discovered when I wrote a book on the evolution of IT in American government agencies. However, this current project may motivate someone now to examine a series of cases in the Federal Government to identify patterns of work, and possibly suggestions for improved performance that would fit within the context of how government works (e.g., its particular form of RFPs, etc.) An IRS IT manager once told me that programming new systems in the Federal Government was like trying to change a flat tire on a car that has to continue moving down the road at 50 miles an hour driven by inexperienced drivers not interested in how the car works or the tires are performing.</div>
<div> </div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Nov 8, 2013 at 8:23 AM, William McMillan <span dir="ltr"><<a href="mailto:wmcmillan@emich.edu" target="_blank">wmcmillan@emich.edu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div>Jim et al., I guess we should have stuck with the Cleanroom methodology of Harlan Mills and colleagues some 30 years ago.<br>
<br></div>Where did they develop that? Oh yeah, some big outfit called IBM.<br>
<br></div><div>Teaching software developers to use disciplined engineering methods is like trying to lasso seagulls.<br></div><div><br></div>- Bill<div><div class="h5"><br><br><div class="gmail_extra"><br><br><div class="gmail_quote">
On Thu, Nov 7, 2013 at 2:06 PM, James Cortada <span dir="ltr"><<a href="mailto:jcortada@umn.edu" target="_blank">jcortada@umn.edu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I had the same practices and same concerns as Ian based on my 38 years at IBM. What I will want to see are the GAO audits that inevitably will appear on the ACA software and on its role out. Paul, you may see those before we do; if so, let us know that they have been published. For those not familiar with the GAO, it is an audit arm of the US Government that reports directly to the Congress and has a reputation for finding the problems with failed projects (not just ICT ones). GAO interviews participants, management, and looks at the paper trail on projects and summarizes its finding in clear English and usually in a 25-25 page report. They make boring reading, but the ones on Obamacare will become best sellers! </div>
<div class="gmail_extra"><div><div><br><br><div class="gmail_quote">On Thu, Nov 7, 2013 at 12:01 PM, Ian S. King <span dir="ltr"><<a href="mailto:isking@uw.edu" target="_blank">isking@uw.edu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><p>On Thu, Nov 7, 2013 at 6:09 AM, Ceruzzi, Paul <span dir="ltr"><<a href="mailto:CeruzziP@si.edu" target="_blank">CeruzziP@si.edu</a>></span> wrote:<br></p><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><br>
I published this brief note on Obamacare as an on-line op-ed for the HIastory News Network. <<a href="http://hnn.us/article/153810" target="_blank">http://hnn.us/article/153810</a>>. As the late Mike Mahoney used to say, the study of software could benefit from the study of history, but few who practice software engineering are aware of even the fact that there was such a report in 1968.<br>
_______________________________________________<br>
This email is relayed from <a href="mailto:members@sigcis.org" target="_blank">members@sigcis.org</a>, the email discussion list of SHOT SIGCIS. The list archives are at <a href="http://sigcis.org/pipermail/members/" target="_blank">http://sigcis.org/pipermail/members/</a> and you can change your subscription options at <a href="http://sigcis.org/mailman/listinfo/members" target="_blank">http://sigcis.org/mailman/listinfo/members</a><br>
</blockquote></div><br><p>Nicely turned, Paul. I believe the practice to which you refer is what I've always called "code review", in which the author explains his code to his fellow software engineer, on the principle that if you can't explain it you don't really understand it. :-) In my years as a test manager at Microsoft I promoted this practice, often over the objections of (primarily young) developers who felt it was a waste of time and somehow an insult to their skill. Sometimes the feedback for code that worked fine was that it wasn't maintainable, another artifact of overly "clever" code written by these young cowboys (and girls). </p>
<p>I, too, find the problems of the ACA rollout disturbing. As I think about what is needed in such a system, from the perspective of someone who has been responsible for more than one global-scope website, I just can't think there's anything new there. Drawing from multiple data feeds and multiple databases, offering a consistent and even compelling user interface, protecting user data - been there, done that, got the t-shirt, wore it out. While software engineering is hardly a mature discipline, these are known tasks addressing known challenges. </p>
<p>I already have a dissertation topic, or this one could be fascinating. :-) </p><span><font color="#888888">-- <br><div dir="ltr">Ian S. King, MSCS ('06, Washington)<br>Ph.D. Student<br>The Information School<br>
University of Washington<br>
<br><font face="times new roman, serif">"Be yourself, everyone else is already taken." - Oscar Wilde</font></div>
</font></span></div></div>
<br>_______________________________________________<br>
This email is relayed from <a href="mailto:members@sigcis.org" target="_blank">members@sigcis.org</a>, the email discussion list of SHOT SIGCIS. The list archives are at <a href="http://sigcis.org/pipermail/members/" target="_blank">http://sigcis.org/pipermail/members/</a> and you can change your subscription options at <a href="http://sigcis.org/mailman/listinfo/members" target="_blank">http://sigcis.org/mailman/listinfo/members</a><br>
</blockquote></div><br><br clear="all"><div><br></div></div></div><span><font color="#888888">-- <br><div dir="ltr"><div>James W. Cortada</div><div>Senior Research Fellow</div>
<div>Charles Babbage Institute</div><div>University of Minnesota</div>
<div><a href="mailto:jcortada@umn.edu" target="_blank">jcortada@umn.edu</a></div>
<div><a href="tel:608-274-6382" value="+16082746382" target="_blank">608-274-6382</a></div></div>
</font></span></div>
<br>_______________________________________________<br>
This email is relayed from <a href="mailto:members@sigcis.org" target="_blank">members@sigcis.org</a>, the email discussion list of SHOT SIGCIS. The list archives are at <a href="http://sigcis.org/pipermail/members/" target="_blank">http://sigcis.org/pipermail/members/</a> and you can change your subscription options at <a href="http://sigcis.org/mailman/listinfo/members" target="_blank">http://sigcis.org/mailman/listinfo/members</a><br>
</blockquote></div><br></div></div></div></div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div dir="ltr"><div>James W. Cortada</div><div>Senior Research Fellow</div>
<div>Charles Babbage Institute</div><div>University of Minnesota</div>
<div><a href="mailto:jcortada@umn.edu" target="_blank">jcortada@umn.edu</a></div>
<div>608-274-6382</div></div>
</div>