[SIGCIS-Members] my "take" on Obamacare

Jon Lindsay jonrlindsay at gmail.com
Fri Nov 8 13:31:28 PST 2013


Indeed, if government never got IT right then Osama Bin Laden would still
be alive, we would know nothing about the universe, and all of us would be
living in a tax-free anarchy that would make even Cormac McCarthy wince. I
would even go so far as to say that it is on the ground of all the success
that the failures stand out so starkly. The froth of innovation and
friction we witness belies the stability of the platforms and prior
applications which make it possible.

While I completely agree with Paul that management lessons of the past
continue to be ignored, I also think it takes some pretty strong willpower
and organizational commitment to learn and implement them. The flexibility
and openness to marginal adaptation which makes IT so generative also makes
it so easy to introduce flaws which can only be addressed through
management as skilled if not more as the programmers themselves.
Information infrastructure is this odd hybrid of reliable successes and
abundant failures.

Lastly, even since sharing Paul's post with some friends of various
political persuasions, I am struck at how hard it can be to get people to
believe that well-meaning failure or non-nefarious oversights can be at the
root cause of healthcare.gov's failure. Incompetence is always more
probable than conspiracy, but I guess this takes a certain historical
perspective to see.

Best,
Jon


On Sat, Nov 9, 2013 at 4:54 AM, Andrew Russell <arussell at stevens.edu> wrote:

> Surely there are some aspects of project management that are specific to
> the US federal government, but the anecdote that Jim cites from the IRS
> sounds quite similar to  anecdotes I have heard about the implementation of
> computing in other large organizations in the private sector - airline
> reservation systems, banking systems, etc - that have a high degree of
> momentum (in the Hughesian sense).  As a result, I'm skeptical that any
> lessons to be drawn here apply only to government agencies.
>
> Unfortunately, the opinion pages prefer to use the healthcare.gov rollout
> to bash government capabilities, which advances a particular political
> agenda at the expense of analytical clarity.  See for example the absurd
> headline from the op-ed pages of the NY Times - "Why the Government Never
> Gets Tech Right" (
> http://www.nytimes.com/2013/10/25/opinion/getting-to-the-bottom-of-healthcaregovs-flop.html).
>  The authors rightly point out that procurement procedures can present
> difficulties (Jim Cortada made a similar point below), but it's quite a
> leap from there to conclude that government *never* gets tech right.  Paul
> Ceruzzi's discussion in his HNN post of the Curiosity Rover is a perfect
> example of the flaws of this sort of reasoning.
>
> Anyway, if "government never gets tech right," then why have we been
> spending so much time in the last few months worrying about the NSA?
>
> Should we now expect the NYT to publish follow-up op-eds about how
> decisions by Licklider, Taylor, Roberts, Kahn, and Cerf fit into the
> "string of information technology debacles by the federal government"??  I
> can't wait to read those ;-)
>
> In any event - thank you Paul for trying to steer the discussion about
> healthcare.gov in a more substantial and productive direction!
>
> Andy
>
>
>
>
> On Nov 8, 2013, at 10:01 AM, James Cortada <jcortada at umn.edu> wrote:
>
> 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.
>
> 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.
>
>
>
> On Fri, Nov 8, 2013 at 8:23 AM, William McMillan <wmcmillan at emich.edu>wrote:
>
>> Jim et al., I guess we should have stuck with the Cleanroom methodology
>> of Harlan Mills and colleagues some 30 years ago.
>>
>> Where did they develop that?  Oh yeah, some big outfit called IBM.
>>
>> Teaching software developers to use disciplined engineering methods is
>> like trying to lasso seagulls.
>>
>> - Bill
>>
>>
>>
>>
>> On Thu, Nov 7, 2013 at 2:06 PM, James Cortada <jcortada at umn.edu> wrote:
>>
>>> 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!
>>>
>>>
>>> On Thu, Nov 7, 2013 at 12:01 PM, Ian S. King <isking at uw.edu> wrote:
>>>
>>>> On Thu, Nov 7, 2013 at 6:09 AM, Ceruzzi, Paul <CeruzziP at si.edu> wrote:
>>>>
>>>>>
>>>>> I published this brief note on Obamacare as an on-line op-ed for the
>>>>> HIastory News Network. <http://hnn.us/article/153810>. 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.
>>>>> _______________________________________________
>>>>> This email is relayed from members at sigcis.org, the email discussion
>>>>> list of SHOT SIGCIS. The list archives are at
>>>>> http://sigcis.org/pipermail/members/ and you can change your
>>>>> subscription options at http://sigcis.org/mailman/listinfo/members
>>>>>
>>>>
>>>> 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).
>>>>
>>>> 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.
>>>>
>>>> I already have a dissertation topic, or this one could be fascinating.
>>>>  :-)
>>>> --
>>>> Ian S. King, MSCS ('06, Washington)
>>>> Ph.D. Student
>>>> The Information School
>>>> University of Washington
>>>>
>>>> "Be yourself, everyone else is already taken."  - Oscar Wilde
>>>>
>>>> _______________________________________________
>>>> This email is relayed from members at sigcis.org, the email discussion
>>>> list of SHOT SIGCIS. The list archives are at
>>>> http://sigcis.org/pipermail/members/ and you can change your
>>>> subscription options at http://sigcis.org/mailman/listinfo/members
>>>>
>>>
>>>
>>>
>>> --
>>> James W. Cortada
>>> Senior Research Fellow
>>> Charles Babbage Institute
>>> University of Minnesota
>>> jcortada at umn.edu
>>> 608-274-6382
>>>
>>> _______________________________________________
>>> This email is relayed from members at sigcis.org, the email discussion
>>> list of SHOT SIGCIS. The list archives are at
>>> http://sigcis.org/pipermail/members/ and you can change your
>>> subscription options at http://sigcis.org/mailman/listinfo/members
>>>
>>
>>
>
>
> --
> James W. Cortada
> Senior Research Fellow
> Charles Babbage Institute
> University of Minnesota
> jcortada at umn.edu
> 608-274-6382
>  _______________________________________________
> This email is relayed from members at sigcis.org, the email discussion list
> of SHOT SIGCIS. The list archives are at
> http://sigcis.org/pipermail/members/ and you can change your subscription
> options at http://sigcis.org/mailman/listinfo/members
>
>
>
> _______________________________________________
> This email is relayed from members at sigcis.org, the email discussion list
> of SHOT SIGCIS. The list archives are at
> http://sigcis.org/pipermail/members/ and you can change your subscription
> options at http://sigcis.org/mailman/listinfo/members
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sigcis.org/pipermail/members-sigcis.org/attachments/20131109/695d709f/attachment-0001.htm>


More information about the Members mailing list