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.
On Thu, Nov 7, 2013 at 6:09 AM, Ceruzzi, Paul <CeruzziP@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@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
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@uw.edu> wrote:
On Thu, Nov 7, 2013 at 6:09 AM, Ceruzzi, Paul <CeruzziP@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@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@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@umn.edu 608-274-6382
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@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@uw.edu> wrote:
On Thu, Nov 7, 2013 at 6:09 AM, Ceruzzi, Paul <CeruzziP@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@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@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@umn.edu 608-274-6382
_______________________________________________ This email is relayed from members@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
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@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@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@uw.edu> wrote:
On Thu, Nov 7, 2013 at 6:09 AM, Ceruzzi, Paul <CeruzziP@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@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@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@umn.edu 608-274-6382
_______________________________________________ This email is relayed from members@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@umn.edu 608-274-6382
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-healthcar...). 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@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@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@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@uw.edu> wrote: On Thu, Nov 7, 2013 at 6:09 AM, Ceruzzi, Paul <CeruzziP@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@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@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@umn.edu 608-274-6382
_______________________________________________ This email is relayed from members@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@umn.edu 608-274-6382 _______________________________________________ This email is relayed from members@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
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@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-healthcar...). 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@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@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@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@uw.edu> wrote:
On Thu, Nov 7, 2013 at 6:09 AM, Ceruzzi, Paul <CeruzziP@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@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@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@umn.edu 608-274-6382
_______________________________________________ This email is relayed from members@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@umn.edu 608-274-6382 _______________________________________________ This email is relayed from members@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@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
participants (6)
-
Andrew Russell -
Ceruzzi, Paul -
Ian S. King -
James Cortada -
Jon Lindsay -
William McMillan