Beki Grinter

Posts Tagged ‘software engineering’

Michael Mahoney: Historian of Software Engineering

In computer science, discipline on November 15, 2009 at 1:16 pm

I’ve come across Michael Mahoney before, but recently I read his piece on the history of the science of Software Engineering

There was a lot more going on in the article than I want to discuss here, but I wanted to bring out a few quotes.

“There is nothing natural about software or any science of software. Programs exist only because we write them, we write them only because we have built computers on which to run them, and the problems we write ultimately reflect the structures of those computers. Computers are artifacts, programs are artifacts, and models of the world created by programs are artifacts. Hence, any science about any of these must be a science of a world of our own making rather than a world presented to us by nature.”

I have often felt that we have done our best to eradicate the human from Computer Science. I like the way that Mahoney layers the humanity into the production of systems.

When I got started in HCI, not that it was called that at Irvine, instead it went by the handy title of CORPS (Computing, ORganizations, Policy and Society — the acronym had the additional advantage that people who wanted to donate their body for medical science would send us email about it too).

OK, back to the point, when I got started in HCI, I felt that the production of systems was given far less attention than the use of the systems. If human use was so key to understanding success, then why wasn’t human production as valued. I thought then, as I think now, that the humanness of producing complex machinery is one reason why it’s not actually as easy to reduce practice to theory.

There’s that quote that “in theory, theory and practice are the same. In practice they are not.” I think humans make the difference. Computers are not machines, they are human built ones, and then as Mahoney says so well these machines run programs that are yet more human built artefacts, to create human built models of a human world. Layers of humanness.

I was interested in the human nature of machine production, software and systems, for many years. I still am. I think that acceptance of this, and a rich detailed understanding of it must complement the work that we do to understand the machine centred aspects of Computer Science.

Mahoney later asks, “who created the science of software, when, where, why and how?” I agree with him that this is a critically important question. Unlocking the legacy of why and for what reasons seems especially valuable as Computer Science continues its rapid expansion and what I think is also its devolution into more distinct parts.

He suggests that a fruitful way to look at science is through it’s practice (yay). He suggests the concept of an agenda, which he describes as “what its practitioners agree ought to be done, a conensus concerning the problems of the field, their order of importance, the means for solving them, and what constitutes a solution” and argues that the agenda also provides “standing in the field by solving the problems with high priority, and especially by doing so in a way that extends or reshapes the agenda, or by posing profound problems”. While, yes, this is obvious in some ways, I still find it interesting to consider. Additionally, perhaps we should also question the processes by which the community go about setting problems. Grand Challenges is one metaphor used in Computer Science, but I have had discussions with colleagues who suggest that that might be overly engineering in focus. And whether I agree or not, I’m open to the idea that the processes by which our agenda is framed are as important as the content, for they too are human-built.

I put this quote on my facebook page “it is curious that to this day, the community distinguishes between computer science and theoretical computer science, as if the former involves some kind of science other than theoretical science. It is not clear what that other kind of science might be nor what is scientific about it.” I got suggestions that that science might be biologically inspired… in the case of protein folding. What I failed, in the course of putting the quote on my page, to do was to describe Mahoney’s position that software as science may also be science as software. In other words software may not only be a science that is being developed, but also a component of other sciences (as I understood it).

I was glad that he and I agree that the importance of an agenda are the resources allocated to it. Of course, but I have pointed out that I think that’s one challenge for HCI4D, particularly w.r.t to the National Science Foundation. I think the goals of the two communities interact in more complicated ways because they did not co-evolve together. So it’s not just how much, it’s how long and how well the resources are aligned to the agenda.

I liked his recommendation of using text books to trace the emergence and development of a discipline. He makes a wonderful argument that they contain the starting points from which the research frontier will be discovered through learning. I love that idea. Text books as codification of what is known, what is discovered, what is done, and a place from which the what is undone is suggested.

Finally, well not for him, but for this post, he suggests that no-one has done a critical documented history of the evolution of the science of Computer Science established itself in universities. Given the numerous paths its taken, as part of mathematics, engineering, and science or in contrast freestanding as is true of my alma mater, Irvine, and my current employer Georgia Tech) As Computer Science and now Information. I agree. The history of the establishment of these departments is overdue. I hope that a historian will take him up.


Academic Organisation

In academia, academic management, computer science, discipline on July 12, 2009 at 1:56 pm

A colleague of mine, Mark Guzdial has written a thoughtful and thought provoking post on his Computer Science Education blog.

And I was drafting a reply, and I decided that I’d like to write it here.

The gist, as I read it, is that he asks why academic disciplines are organised by outcome rather than by methods. By asking this question you can explore other connections.  In the case of Computer Science Education it turns the focus away from outcomes (measures of learning success, and towards the experiences that will create these desired outcomes, what is the experience of good education).

This got me thinking about what I see as an interesting difference between some of the sciences and others, which has some origins in methods, and theories.

I’ve spent most of my research career as a practicing Computer Scientist. My education is reasonably traditional, and my career has been entirely within institutions focused on the advancement of Computer Science. But, that said, I’ve spent my research career as a user of methods/theories that do not hail from Computer Science, but from Sociology/Anthropology.  And to do that I’ve done my best to learn about the disciplines. And in that journey, I’ve been continuously struck by the volume of debate within those disciplines.

Specifically, I’m struck by how much discussion and difference there is in methodology and theory within both disciplines. My analogy, what would it mean if we had multiple and competing approaches to Computer Science. And I suppose we do. I understand that there are significant philosophical differences within AI. But, I don’t think we teach Computer Science in ways that amplify and centralise those philosophical differences.  I am aware that these differences exist, but I’ve never had a class or seen a book that talks about these philosophical differences and why they exist, and what their origins are.

Are we poorer for that? I increasingly think so…

Another example. I used to be a Software Engineer (which explains why I still review papers for ICSE I suppose, and why I can’t stop subscribing to Software Engineering Notes). So there are a variety of different methods to organizing the work of Software development. Some of the new Agile or Pair-Programming techniques contrast with the Chief-Surgeon model. And while I have read arguments about the differences, and the outcomes and experiences that they make possible (in pair programming people share a machine, so we say that it’s a good way to learn and a good way for the person watching to catch mistakes of the person typing, we argue that that comes with a certain productivity hit because there are half the number of machines in operation, and so we continue…)…

So we have those debates, based on outcomes, and elements of the experience (which we conveniently blur into the debate), but we never really systematically unpack and discuss the many different ways that work can be divided. (My first advisor Rob Kling told me never to use the word organization as a noun—it was a convenient gloss over the vast array of organizational types—I think he’s right). Organization is a verb, and it is the division of labor and the assumptions that frame that particular set of institutional arrangements.

And I think in disciplines where there is lots of debate about the philosophical nature of the world, there’s far more explicit discussion of the theories and methods and their explanatory power as it relates to that particular set of philosophical commitments. I think Computer Science could benefit from the same approach. Why do we disagree? What does the nature of the disagreement tell us about the nature of the world?

Perhaps we don’t because we focus on the machine (for example, explaining differences as technical tradeoffs, or as a science of the innards of the machine itself). But, I think that those machines do not exist in a world in any way without the presence of humans. The computer was a human creation. It is imagined and built for humans, with human-centered goals (such as faster machines capable of solving more complex problems, relying on novel algorithms, protocols, and architectures). Our philosophy turns in significant part on a belief that what is done in the machine is justifiable because it makes advances possible but those advances are human.