Join us to discuss the broken software engineering pipeline on Monday 1st of July at 2pm BST

Pipeline icon via

Many employers struggle to recruit and retain software engineers with the skills needed to contribute to the modern workplace. What do employers and educators need to do to address this wicked problem? Join us to discuss the broken pipeline problem and its potential solutions in cybersecurity and beyond on Monday 1st July at 2pm BST. We’ll be joined by Shamal Faily and James Sharp from the Defence Science and Technology Laboratory (DSTL – an executive agency of the UK Ministry of Defence – MoD) who will give a lightning talk summary of their paper published at the High Integrity Software Conference (HISC) in 2024. From the abstract:

Industry sectors producing High Integrity software, like Defence and Aerospace, require a consistent and reliable supply of software engineering suitably qualified and experienced persons (SQEP). Much of this SQEP is drawn from UK Computer Science undergraduate programmes. However, these sectors face several challenges meeting the quantity and quality of the desired supply. First, classic but relevant material on Software Engineering is slowly being de-emphasised from Academic Computing programmes, and even removed from specialist programmes such as Cyber Security. For example, at several institutions, modules on Software Engineering have been replaced with more restricted material on Software Design, often delivered in the first year of a degree programme. Second, because of how degree and apprenticeship accreditation criteria are interpreted, foundational topics on software requirements and specifications are delivered inconsistently. On some programmes, user needs and software requirements are considered to be synonymous. On others, material that is covered early in the curriculum is not reinforced in later years, once students begin to encounter non-trivial systems. Third, as Software Engineering is no longer an active area of research in the UK, the SQEP available to deliver best practice and research results in Software Engineering is becoming eroded. This has implications on the ability to teach material such as Model-Driven Software Engineering, but also on what ‘software engineering’ is understood to be. For example, many ICT projects employ agile methods where code is valued over documentation. Software for many critical systems is too complex to reason about independently, and – given the life span of such systems – non-software artefacts are essential for activities like validation, knowledge exchange, and certification. To begin addressing these challenges at scale, we propose three possible solutions. First, we must talk more widely about the Software Engineering SQEP pipeline problem. The more awareness there is of this pipeline problem, the more likely it is different stakeholders will start collaborating to strengthen the pipeline. Second, to halt further erosion of the Software Engineering curricula, degree accreditors need to be prepared to identify and call out anti-patterns in Software Engineering education. This should not be a punitive process, but a vehicle for proposing remediations, albeit as a pre-requisite for continued accreditation. Third, material on software certification should be embodied into the Software Engineering curriculum for all Computer Science course derivatives. Safety and Security is increasing expected by consumers in systems of all shapes and sizes, driven by a need to introduce automation throughout everyday life. Introducing a focus on certification will encourage innovation research and education around how to do this at the same pace as modern software engineering. Moreover, those with cogent knowledge should also be prepared to share it, to ensure a certification curricula can be delivered at scale across all UK HEIs.

All welcome, as usual, we’ll be meeting online joining details at


  1. Faily, S and Sharp, J (2024) The Software Engineering SQEP Pipeline Problem: Challenges and Opportunities (slides and abstract available online)