STRIDE will investigate resilience and automation in the socio-technical system that supports software development, a system that includes people (engineers, users, managers), technical infrastructure (tools, development environments), processes (lean, requirements elicitation) and artefacts (code, wiki, coding standards). Breakdowns in socio-technical systems can cause significant disruption and Resilience Engineering aims to avoid them by emphasising what works, so that resilience can be preserved. From this perspective, resilience is defined as the productive tension between stability and change, always with the aim of producing systems that are “safe”. This view of socio-technical systems is pertinent to modern software engineering where change has become endemic: with changing requirements, advanced technologies, complex infrastructure and new security threats. In addition to the constantly changing environment, software production is increasingly being automated, which requires repeated re-balance of this tension. But what is the relationship between resilience and automation?

While improvements to software development brought by automation are vital to keeping software safe and secure, automation is not a silver bullet.

“Making a system safer involves coupling the capabilities of humans with the technology they work with so that they can stay in control”1. What does that mean for software development? Is there something fundamentally human that needs to be retained as part of the software development process? And if so, how can a productive and resilient balance between human control and automation be maintained in the context of constantly increasing automation? How can automation be used to increase socio-technical resilience and what will be the impact on resilience of different levels of automation?

STRIDE aims to address these and related questions. The project will determine and operationalise factors that indicate socio-technical resilience (STR) of software development, drawing on social psychology and resilience engineering, and grounding the research in the concrete development task of automated fault localisation. We will engage with representatives of two developer communities: commercial software engineers and professional end user developers who represent two different development environments. This work will have particular implications for improving STR and the pace and nature of automation in the software development lifecycle.

1 Back, J., Furniss, D., Hildebrandt, M., & Blandford, A. (2008). Resilience markers for safer systems and organisations. International Conference on Computer Safety, Reliability, and Security, 99–112. Springer