Developing educational technology is not simply a technical challenge or a pedagogical challenge. It is both. The most successful digital learning solutions balance educational effectiveness with processes that ensure quality, maintainability and long-term sustainability. In this article, Prof. John Traxler explores the origins of software engineering and courseware engineering, examining what these disciplines can teach us and why many of these ideas remain relevant today.

What Engineering Can Teach Educational Technology

Author: Prof. John Traxler, UNESCO Chair, Commonwealth of Learning Chair and Academic Director of the Avallain Lab

St. Gallen, June 26, 2026 – Educational technology is often discussed in terms of pedagogy or innovation. Less attention is paid to how educational technology itself should be developed and maintained. Yet many of the challenges facing educational technology today, including quality, scalability, sustainability and cost, are not new. They are challenges that software engineering has been grappling with for decades.

The Origins of Software Engineering

This needs a bit of history. 

Decades ago, perhaps fifty or sixty years ago, computer programs were written ‘by hand’ by skilled, expert people called ‘programmers’, and these programmers were pretty much the totality of the computing workforce, able to do new and wonderful things on a daily basis. So, of course, expectations and ambitions grew bigger and bigger, and, in due course, so did the awareness that things were going badly wrong. What were called programs came to be called projects or systems. The biggest and most ambitious – and the most expensive – were routinely over budget, overrun and not what had originally been required. Even those on time were often unmaintainable and thus quickly unusable as their environment changed.

It became apparent that programs or software systems were not merely slabs of code but large and complex artefacts, comparable perhaps to suspension bridges, power stations or ocean liners. The latter were all developed at huge cost and under contract, respectively, the products of the established disciplines of civil engineering, electrical engineering and nautical engineering. So perhaps programmers should be asking themselves: what constitutes ‘engineering’, what can we learn from it, and whether such a thing as ‘software engineering’ is a possible solution to the growing failings and concerns.

People working with software, both in industry and academia, began to itemise the tools and techniques common across engineering disciplines and assess their relevance to their own work. Some of the tools and techniques they came up with include, among others, mathematics and formal notation, structure and development phases, project management, process modelling, quality assurance, modularity, cost estimation, prototyping, maintenance, usability, design, requirements engineering and specification.

Bearing in mind the need to acknowledge the major difference, namely, that software is just instructions and data, items that need no raw materials and will not rot or rust. It was also worth recognising that complexity alone does not make something an engineering problem; ‘The Lord of the Rings’, both book and film, are large and complex artefacts but were not apparently consciously engineered. The question then became how engineering tools and techniques could be adapted and adopted for software development.

From Engineering to Software Engineering

Part of the problem was not fully understanding what the customer required. Often, the customer did not fully understand the requirements themselves or could not explain them adequately, creating a need to express those requirements completely and unambiguously. Consequently, models, prototypes and diagrams came into the picture, and so too in some cases did the mathematical expression of these requirements. Here, I am thinking of obscure, well-established ‘formal methods’ and their notations, such as Z (Z Notation), VDM (Vienna Development Method) and CSP (Communicating Sequential Processes), which are mathematical approaches used to specify software requirements precisely and unambiguously. 

For anything beyond trivial requirements, producing a software system requires breaking it down into components, often through top-down decomposition, reducing one big requirement into progressively smaller ones. It might also involve reusing previously trusted components and representing how these components were connected, while managing and monitoring the processes by which the product was developed. Then, at the same time, recognising that the requirement may change as the development proceeds or its environment evolves. Costs needed estimating, predicting and controlling, and developers needed the reassurance that a lengthy and complex development process was, at each stage, not deviating from what was required, ready for a final handover where money and software would be exchanged in ways that showed, incontrovertibly, that everything was as it should be, contractually, and nothing as it shouldn’t. 

Often, these lengthy and highly structured development processes were outpaced by an evolving external environment, customers’ evolving understanding or the increasing need to involve actual users in the development process. This led to other approaches, including RAD, the self-explanatory Rapid Application Development, using more and more powerful simulations, prototypes, tools and languages, which shorten development and delivery times. Sometimes, however, poor documentation and structure meant higher costs down the line in the form of maintenance. RAD’s instinct to iterate quickly, involve real users and ship working software early, did not fade so much as harden, first into the Agile movement of the early 2000s, and later into DevOps and continuous delivery, which remain the dominant ways software is built today.

Courseware Engineering

It became obvious that, just like software systems in general, courseware, a term invented to make an analogy with software and to recognise that courseware, namely educational software packages, was also often composed of large and complex artefacts that needed to be engineered, but in a form specifically for education. Courseware arrived, however, with baggage that included competing educational theories, multiple stakeholders and, compared to mainstream software, more interactional complexity and less computational complexity.

It did, however, still require time and effort to develop, and so, among other techniques and tools, courseware cost estimation evolved to account for the costs of different kinds of interaction, media and logic. Ian Marshall at Abertay¹, and others, worked from contemporary industry data to refine the factors and parameters in the equations, and also on the ratio of time taken to develop vs time of usage by an individual learner. The other side of this, pitched against the cost of different media and interactions, was their respective pedagogic efficiencies and how each might relate to different pedagogic strategies, pedagogic ‘bang-for-your-buck’.

Several projects started from the ‘conversational framework’ of digital learning articulated by Diana Laurillard; her ‘Rethinking University Teaching’² of 2002 is still required reading around the world and remains widely cited worldwide. This framework portrayed formal teaching and learning as interactions – ‘conversations’ – between the teacher’s conceptions and the learner’s conceptions and how the teacher had to devise situations or artefacts in the real world, meaning the usual formats like lectures, set books, assessments, lab experiments, field trips, seminars, group projects and online chat, that would enable the teacher’s conceptions to change the learner’s conceptions, meaning the learner would have learnt something from the teacher.

Each of these situations or artefacts could be classified into one of four broad categories: acquiring, inquiring, producing and practising. The framework was sometimes extended beyond individual learners to groups of learners, and these, too, had their pedagogic artefacts and situations, classified as discussion or collaboration. Of course, they could also each be analogue or digital, synchronous or asynchronous, remote or present, though some of the possibilities might be daft.

These two threads, the cost of developing different functions within educational software and the ways in which these functions map onto various educational situations and artefacts, come together with research that calibrated the various educational situations and artefacts. 

Educational situations and artefacts simply refer to lectures, readings, workshops, field trips, seminars, games, coursework, examinations, practicals, role-play, tutorials, simulations, essays and projects. Then everything digital that evolved from these, web quests, webinars, lecture capture, etc., etc., etc. Researchers attempted to measure their respective educational effectiveness, perhaps in terms of something as simple as the proportion of material that was remembered, understood or applied. In short, this amounted to a form of cost-benefit analysis. For large online universities, the value of such analysis was obvious and widely exploited.

The obvious examples are Laurillard’s CRAM, Course Resource Appraisal Model, now in use at London’s UCL³ and Conole’s Media Advisor⁴.

Summing Up

All these ideas, many rooted in the last century, remain relevant, even if the numbers and technologies have moved on; we are still trying to produce high-quality, maintainable and pedagogically effective educational digital technology with cost-effective, managed and sustainable processes. This piece starts with a fairly general critique to home in on a point at which education, technology and commerce converge in ways that remain relevant.

The lesson from software engineering and courseware engineering is not that educational technology should become more technical. Rather, it is that successful educational technology requires the same rigour, planning and discipline that other mature engineering fields developed in response to complexity.

These principles may matter more than ever as Generative and Agentic AI reshape our processes, our products, and the very nature and delivery of learning.

References

1. Marshall, I.M., Samson, W.B., Dugard, P.I. (1994). A proposed framework for predicting the development effort of multimedia courseware. In: Herzner, W., Kappe, F. (eds) Multimedia/Hypermedia in Open Distributed Environments. Eurographics. Springer, Vienna. https://doi.org/10.1007/978-3-7091-9361-7_12 ↩︎
2.  Laurillard, D. (2002). Rethinking university teaching: a conversational framework for the effective use of learning technologies (2nd ed.). London: Routledge Falmer. ↩︎
3. Kennedy, E., Laurillard, D., Horan, B., & Charlton, P. (2015). Making meaningful decisions about time, workload and pedagogy in the digital age: the Course Resource Appraisal Model. Distance Education, 36(2), 177–195. https://doi.org/10.1080/01587919.2015.1055920 ↩︎
4. Conole, Grainne (2002). Systematising Learning and Research Information. Journal of Interactive Media in Education, 2002(7) ↩︎

---

About Avallain

For more than two decades, Avallain has enabled publishers, institutions and educators to create and deliver world-class digital education products and programmes. Our award-winning solutions include Avallain Author, an AI-powered authoring tool, Avallain Magnet, a peerless LMS with integrated AI, and TeacherMatic, a ready-to-use AI toolkit created for and refined by educators.

Our technology meets the highest standards with accessibility and human-centred design at its core. Through Avallain Intelligence, our framework for the responsible use of AI in education, we empower our clients to unlock AI’s full potential, applied ethically and safely. Avallain is ISO/IEC 27001:2022 and SOC 2 Type 2 certified and a participant in the United Nations Global Compact.

Find out more at avallain.com

_

Contact:

Daniel Seuling

VP Client Relations & Marketing

dseuling@avallain.com