Software without boundaries
Bashar Nuseibeh
There is a common misconception that software engineering is a discipline for managing the production of programs that run on computers. It is true that a significant artefact that software engineers produce is code: descriptive instructions to machines that enable them to perform what we humans require. However, the ubiquity of software in society has meant that we cannot, and should not, think of software purely as a way of mediating between humans and machines. Rather it is also a reflector, enabler, and disrupter of the very way we live our lives. It then follows that software engineering should be about representing and extending the lived experience, supported by software but not bounded by it.
Such a framing means that the scope of the discipline – reflected in its various research agendas, its educational offerings,?and its industrial practice – must continue to extend beyond its traditional technical boundaries, to reflect the inherent socio-technical nature of its processes and outcomes. That is not to say that the foundations of software engineering such as mathematics, logic and analytical methods are less important, but simply to reflect what we have always known: that the human and social context in which people experience life must also be accounted for in the development of software-intensive systems. Such a context requires an engagement with societal concerns in ways that typical software engineering methods do not reflect nor facilitate.
This is not simply a call for inter-disciplinarity – talking to and engaging with social scientists, economists, and “end users” of software is not enough. It is about radically re-thinking the discipline of software engineering itself so that the artefacts it produces are not only a precise set of technical specifications and instructions to a technological machine, but the very embodiment of the psycho-social experience. Representations of the essence of being human and being social, such as how we see ourselves, our emotions, and our values, must have a place in the software programs that we write and the software systems that we assemble.
领英推荐
This is not necessarily a view that is accepted by all in the software engineering community, but one that I believe is needed to elevate the discipline to its rightful place as a hub of innovation, debate, and influence in the post-digital world – a world in which it is harder, even foolish, to determine where human activity stops and where technology starts. I don’t have a catchy name for such a world – "cyber-physical-social" is a mouthful – but I do have an aspiration that my discipline of software engineering lies at the heart of building it.
And if we software engineers are to extend our role to be leading actors on the societal stage, then we also need to play our part responsibly: responsible in the way we conduct our research, responsible in the way we engineer our software, and responsible in the way we consider the impact of our software deployments. And responsible also means accountable. It is no longer acceptable to simply reflect on accidental or malicious software-related incidents after they occur. Security breaches, discriminatory algorithms, and unusable, disruptive, or invasive systems are neither software failures nor social failures, they are failures to consider software issues as socio-technical, requiring a deep engagement with the inevitable intertwining of technology and society, and requiring a new discipline of?responsible software engineering.
Bio:?Bashar Nuseibeh is Professor of Computing at The Open University, UK. He was Chief Scientist of Lero – The Irish Software Research Centre, at the University of Limerick. He is an Honorary Professor at University College London (UCL), and a Visiting Professor at the National Institute of Informatics (NII), Japan, and University College Dublin (UCD), Ireland. He is a Fellow of the Royal Academy of Engineering, and member of the Royal Irish Academy and Academia Europaea. You can follow him on Twitter @BNuseibeh.
Curious & creative, exploring tech, cultures & science. Passionate about art & science, inspiring positive impact. Embracing challenges, enjoying life's journey
1 年Eduardo Monesi
Data and Intelligence
2 年I've just finished reading Annemarie Mol's book The Body Multiple on medical ontology, which takes a detailed and theoretically grounded look at the overlapping but distinct practices in a Dutch hospital. It questions what exactly are the objects that these practices are working on, how the different narratives come together (or not), with explicit reference to cultural, commercial, political and ethical factors. I'm wondering if a similar approach has been or could be applied to software engineering? cc Bashar Nuseibeh Sergio de Cesare
AI & Tech Leader | Strategic Advisor | Bridging Innovation & Business
3 年I can fully confirm your thoughts and observations. While there are “trending” topics such as “Ethics in AI” where many join the discussion, there are many more “less attractive” aspects in software engineering. It helps me to structure related concerns into P^3: Product, People, Process categories. And these are, from my experience, deeply connected. Architecture decisions are made by a team and its communication as well as working values will have an impact. The balance between internal and external staff does, too. And of course, the organizational context, it’s ability to react quickly or slowly, will impact the final possible value delivered. These aspects become certainly very obvious when discussing the transfer of new ideas and technologies from concept to industrial strength applications. All hurdles and challenges will appear, I promise! :-)
Bashar, I think what you’re heading toward here is a view of software engineering that is analogous to architecture’s role in creating the built environment. Architecture students study something akin to engineering (let’s not quibble exactly about the boundaries) but their discipline incorporates aesthetics and building occupants’ lived experience too. These are studied as integral to architecture, not elective add-ons. For too long, software engineering researchers and educators - influenced by their counterparts in other branches of engineering - have said that these issues are tangential to or outside their areas of expertise and concern. In other branches of engineering this may be excusable, but software engineers are as responsible for the virtual environment we all live in today (think of the non-tangential effects of Facebook) as architects are for the built environment. Architecture is responsible for abominations, but the difference is that architectural criticism doesn’t let them excuse themselves with the claim that they were just meeting customer specifications. Perhaps it’s the existence of critics that is the hallmark.
Senior Staff Software Engineer at Ocado Technology
3 年Great post - I think you've hit on something really important. In my own meagre way I've been thinking a lot about meaning and intentionality. What are we actually doing when we write software? We intend for some outcome, some effect in the real world. Often, instead of making the link between the social and computational contexts explicit, we rely on winks and nudges to other software developers through aspects like variable naming and testing. To pick a toy example, calling your class "BankAccount" instantly brings forth a whole cluster of subtle assumptions, expectations and intentions. But does that software actually interact with our social reality in way that realises the metaphor? If not, how do you encode the value system of the bank?