David Millard

Over the last few months I have been co-organising a workshop for this year’s Web Science Conference on interdisciplinary; the aim is to collect together interdisciplinary experiences (from Coups and Calamities) and reflect on some of the disciplinary differences that make Web Science research so interesting. It has caused me to pause and reflect a bit on my own interdisciplinary experiences.

Now, Computer Science is my discipline, it was my first degree, the place I learned my first professional skills, and remains a comfy place to metaphorically hang my hat. And at the heart of Computer Science is Software Engineering (in my view the very best kind of mind-bending, reality-altering Engineering).

In my experience of interdisciplinary work Computer Science gets a fair bit of respect. Software Engineering… not so much.

The problem is that to an outsider Software Engineering is utterly opaque. A problem goes in one end, and a software solution pops out the other. The choices made in the production of that software are not visible, often the reason for those choices is technical and difficult, and sometimes the outcomes can appear superficially simplistic.

When I first got involved in interdisciplinary work I was particularly sensitive to this criticism. I was very aware for example that the models of narrative we were using were simplistic, and sometimes based on aging theoretical approaches. When presenting computer science research to a mixed audience I was conscious of the assumptions that I had made in order to build the systems, and how limited they might appear to a room of sociologists or literary theorists.

But now I see that these kinds of assumptions and simplifications are not a product of a weakness in Software Engineering – they are a product of its strength. Where the Humanities are out to explore the rich complexity of the world, engineers are out to simplify it. Not because they are naive, but because it is necessary to build working systems. I think its one of the fundamental tensions of interdisciplinary work in Web Science.

The truth is that Software Engineering is brutal. To make a system work, and work well, all extraneous detail has to be set aside, extreme decisions have to be made, and reality has to be compressed, folded, and made workable. Software Engineering has no qualms about what is truthful, no second-thoughts about generalisation, and does not hesitate to kill its darlings to make the damn thing work. Sometimes to hammer, and thump, and drag software kicking and screaming out of alpha-testing and into real use.

And far from being a weakness this brutality is a skill. It’s a skill we spend years teaching into our undergraduates, and honing in our careers. Software Engineers are professional brutes!

That said, I have written before about the need to resurrect the old notions of cognitive and macro ergonomics in order to design better software systems. In simple terms this is about understanding the context of software in order to make better-informed decisions during the design process. Often decisions that seem unimportant to engineers can be vital to users, and things that might be stripped away because they seem overly complex or expensive can turn out to be crucial to long-term and real-world success.

So the challenge for interdisciplinary work is not to make us Software Engineers suddenly reflect the full, glorious complexity of the world in our data models and algorithms, rather it is to change the criteria for identifying those things that really matter. And then we can let our inner Jekyll loose on the rest of them!

This must start with respecting this brutal spirit, acknowledging it as a necessary process and a potent skill, and then harnessing it for a more sophisticated end.

Software Engineers talk a lot about the 80/20 rule. The idea that you get 80% of the way with 20% of the effort. That’s where we are now in terms of our information systems. We have accomplished much with the brutality we inherited from early computer scientists, and have changed the world without substantially changing ourselves. But now we’re in the 20% zone. There is still much to be done, but to do it will require new skills, new engineering, and new disciplinary partners.

Now the hard work begins.