History of Software Engineering
From craft programming and the “software crisis” to methods, integrated environments, Agile, DevOps, cloud, and generative AI.
This page is not an exhaustive history of the field, but a commented chronology of the idea of software engineering: the emergence of the problem, its naming at the end of the 1960s, the successive attempts to discipline the software process, and the recent transformation of the profession under the pressure of platforms, continuous development, and artificial intelligence.
The term software engineering became established through the NATO conferences in Garmisch (1968) and Rome (1969). The problem, however, was older: programs had become too large to be controlled by individual talent alone, while operating systems, compilers, industrial applications, and real-time systems required methods, documentation, organization, and engineering responsibility.
Personal thread: from portability to interform and integrated environments
In my own trajectory, my entry into software engineering first came through the problem of portability: portable languages, intermediate codes, macroprocessors, and tools able to reduce dependence on a hardware platform or an operating system. BCPL, INTCODE, STAGE-2, and JANUS represented for me a first concrete form of the question: how can a program be detached from the machine on which it runs?
In the 1980s, the question shifted from program portability to the modeling of the design process. From this came the concepts of abstract machine, intermediate form, or interform, as well as the idea of a CAD/CAM environment for program development. The INTERFORM system was an attempt to materialize this vision in an assisted development environment in which the software product was no longer only code, but a succession of representations, decisions, and controlled transformations.
The book Integrating Tools for Software Development, published by Prentice Hall in 1992, synthesized this direction: the software process was seen as a universe made up of objects, activities, agents, and tools, while the integrated environment became the space in which the development and evolution of programs could be supported, organized, and partially automated.
1940–1968 – The prehistory of software engineering
Programming as a difficult craft
In the first decades of electronic computers, programming was closer to craft than to engineering. The programmer was often designer, coder, and operator at the same time, while the dominant cost of computing systems was still hardware. Yet complexity grew rapidly: assembly languages, compilers, subroutine libraries, operating systems, time-sharing, and technical or military applications appeared, and they could no longer be controlled through individual improvisation.
- the 1940s – Programming is carried out very close to the machine, through numerical codes, wiring, or incipient assembly language.
- the 1950s – The first compilers, high-level languages, and program libraries appear; the program begins to become an artifact separate from the machine.
- 1957 – FORTRAN shows that scientific programming can be raised to a level of abstraction acceptable to engineers.
- 1958–1960 – ALGOL introduces a more rigorous model of programming languages and influences the formal culture of programming.
- the 1960s – Operating systems, compilers, and real-time applications become large programs, difficult to test, document, and maintain.
- 1968 – Edsger Dijkstra’s letter on the goto statement expresses the need for programming that is easier to understand, verify, and maintain.
1968–1975 – The birth of the field: the software crisis
The NATO conferences and the naming of the problem
The NATO Conference in Garmisch, held in October 1968, had the merit of bringing together researchers, manufacturers, users, and academics to discuss a problem that had become critical: the difficulty of producing reliable, maintainable software on time and at predictable cost. Good programming practice was not invented there, but a new discipline, with engineering aspirations, was named.
- 1968 – The NATO Conference in Garmisch consecrates the expression software engineering.
- 1969 – The second NATO conference, in Rome, continues the discussion on techniques, methods, and the organization of software production.
- 1970 – Winston Royce publishes his paper on the development of large software systems; the sequential model will later be associated, sometimes simplistically, with the “waterfall” model.
- early 1970s – Structured programming, program verification, rigorous specification, and the first systematic approaches to the life cycle develop.
- 1972 – David Parnas formulates criteria for decomposing systems into modules, focusing on the hiding of design decisions.
- 1975 – Fred Brooks publishes The Mythical Man-Month, criticizing managerial illusions in large software projects.
This is the period in which the fundamental opposition that will remain present throughout the history of the field takes shape: software must be produced with engineering discipline, yet its matter is immaterial, modifiable, and dependent on people, languages, contexts, and changing requirements.
1975–1985 – Structuring, modularization, formal methods
The program as an object of design
After the NATO moment, attention shifted toward concrete means of disciplining programming: structured programming, modular design, formal specifications, testing, documentation, and configuration control. The program was no longer seen only as executable text, but as the result of a design process.
- structured programming reduces the arbitrariness of control flow and pursues program intelligibility.
- modularization introduces architectural criteria for dividing the system, not merely divisions according to execution flow.
- formal specifications seek precise descriptions of behavior before code.
- testing and verification become autonomous activities of the life cycle.
- software project management attempts to estimate cost, time, risk, and productivity.
During this period, software engineering is still strongly connected to languages, compilers, and programming methods. Yet the central idea already appears: the real difficulty is not only writing code, but controlling the transformations through which a requirement becomes a functioning system.
1985–1995 – Integrated environments, CASE, software process
From method to environment
In the 1980s and early 1990s, the idea emerged that methods are not enough without tools. Integrated development environments, CASE tools, configuration management systems, generators, specialized editors, and attempts at partial automation of the life cycle appeared. At the same time, software engineering developed its own reflection on the software process.
- 1981 – COCOMO, proposed by Barry Boehm, provides an influential model for estimating software cost.
- 1981–1987 – My research on the abstract machine, interform, and software design methods proposes a model of the progressive transformation of program descriptions.
- 1985 – My paper on an intelligent CAD/CAM system for software development shifts the emphasis from model to assisted software workshop.
- 1987 – INTERFORM is presented as a CAD system for program development, with a layered architecture and design-assistance functions.
- 1988 – Boehm’s spiral model places risk and prototyping at the center of the development process.
- late 1980s – CASE promises to integrate analysis, design, documentation, and code generation, but often falls short of industrial expectations.
- 1992 – Integrating Tools for Software Development proposes a vision of integrated environments based on objects, activities, agents, and tools.
In retrospect, this stage was perhaps the moment when software engineering most strongly dreamed of an equivalent to the industrial workshop: a coherent technological space in which program development would be supported by models, intermediate representations, cooperating tools, and a memory of design decisions.
1990–2000 – Objects, components, UML, maturity models
Architecture, reuse, and standardization
The 1990s were marked by the triumph of object orientation and by the search for common modeling languages. C++, Smalltalk, Java, the Booch, OMT, and OOSE methods, and later UML, offered a shared vocabulary for classes, objects, collaborations, and architectures. At the same time, maturity models tried to transform software organizations into organizations capable of knowing and improving their own processes.
- 1991–1993 – CMM, developed at the Software Engineering Institute, introduces the idea of organizational maturity of software processes.
- 1994 – Design Patterns establishes a language of recurring solutions in object-oriented design.
- 1995 – Java contributes to the spread of object-oriented programming and portable applications on distributed infrastructures.
- 1997 – UML becomes an OMG standard and attempts to unify object-oriented notations and methods.
- late 1990s – Components, middleware, and distributed architectures change the scale of software systems.
This stage consolidated the architectural language of software engineering, but also produced a reaction: heavy methods, excessive documentation, and overly rigid formalized modeling were perceived by many teams as a brake on rapidly changing requirements.
2001–2010 – Agile, open source, software as a service
The reaction against heavy methodologies
The Agile Manifesto of 2001 expresses a shift in emphasis: individuals and interactions, working software, customer collaboration, and responding to change. Software engineering does not disappear, but the relation between planning and adaptation changes. Short iterations, continuous integration, automated testing, refactoring, and rapid feedback replace the great initial design.
- 2001 – The Agile Manifesto legitimizes methods such as Scrum, XP, and feedback-centered iterative development.
- the 2000s – Open source becomes a major force in software production and changes the relationship between community, industry, and intellectual property.
- 2005–2010 – Software as a service, web applications, and cloud infrastructures modify the idea of delivery: the software product becomes a permanently updated service.
- late decade – Continuous integration and automated build/test practices prepare the transition to DevOps.
Agile was not only a method, but also a cultural critique of bureaucratized software engineering. Yet Agile’s victory also had a side effect: part of the engineering reflection on architecture, documentation, and modeling was marginalized in favor of speed and immediate adaptation.
2010–2020 – DevOps, cloud, platforms, and continuous software
Software no longer ends
In the 2010s, the center of gravity shifted from building a product delivered periodically to the continuous operation of a service. DevOps, cloud computing, microservices, containers, Kubernetes, infrastructure as code, and observability radically changed software engineering. The line between development, testing, delivery, and operations became blurred.
- 2010 – Continuous Delivery formulates practices for fast, safe, and repeatable deliveries.
- 2013–2014 – Docker and Kubernetes accelerate the standardization of containerization and application orchestration.
- the 2010s – Microservices and APIs transform the software system into a network of autonomous services.
- 2016 – Site Reliability Engineering practices bring the discipline of large-scale operations to the center of software engineering.
- late decade – DevSecOps and software supply-chain security become critical themes.
At this stage, software engineering becomes less and less a discipline of designing an artifact and more and more a discipline of ecosystems: platforms, services, delivery pipelines, monitoring, operations, and organizations capable of continuous learning.
2020–present – Generative AI and the transformation of the profession
From tool to uncertain collaborator
Large language models and Copilot-like tools have introduced a new rupture: for the first time, code generation, program explanation, test writing, and even refactoring can be partially delegated to a conversational system. This does not eliminate software engineering, but it changes its center: from the direct writing of code to the formulation of intent, verification of the result, integration, governance, and quality control.
- 2021 – GitHub Copilot popularizes the idea of an “AI pair programmer”.
- 2022–2024 – Conversational models become everyday tools for generating, explaining, and transforming code.
- 2024–2026 – Software agents appear that can propose broader changes, create pull requests, and participate in development workflows.
- present – Human verification, automated testing, security, and the ability to understand code the engineer did not write directly become increasingly important.
The paradox of the moment is that AI seems to reduce the time needed to write code, but increases the importance of control activities: validation, audit, integration, testing, security, observability, and responsibility. The software engineer becomes less a scribe of code and more a supervisor of a techno-organizational process in which code may be produced by people, tools, or agents.
Is software engineering in decline?
The decline of the classical form, not the disappearance of the discipline
One may speak of decline only if by “software engineering” one means the classical, autonomous discipline centered on methods, life cycles, documentation, formalized design, and integrated environments. Software itself is not in decline; on the contrary, it has become the invisible infrastructure of society. What is rather in decline is the old image of software engineering as a separate field, with clear boundaries, stable methods, and an ideal process from specification to implementation.
Three forces have contributed to this dilution. The first is Agile, which often replaced explicit method with continuous adaptation. The second is DevOps, which absorbed development into the permanent flow of operations. The third is generative AI, which transforms code from the product of an exclusively human activity into a result negotiated among intent, model, context, and verification. From this point of view, software engineering does not die, but loses its classical form and is redistributed into platform engineering, architecture, security, data engineering, AI engineering, and governance.
If the first software crisis was the crisis of producing large programs, the current crisis is the crisis of control over software systems that change continuously, depend on external ecosystems, and can be generated partly by statistical models. The question is no longer only “how do we write correct programs?”, but “how do we preserve intelligibility, responsibility, and control in a world where software is continuous, distributed, and assisted by AI?”.
Summary by stages
| Period | Characterization | Landmarks |
|---|---|---|
| 1940–1968 | Prehistory of the field | Compilers, FORTRAN, ALGOL, operating systems, time-sharing, incipient structured programming. |
| 1968–1975 | Birth of software engineering | NATO conferences, software crisis, Royce, Dijkstra, Parnas, Brooks. |
| 1975–1985 | Disciplining programming | Structuring, modularization, formal specifications, verification, testing, estimation. |
| 1985–1995 | Methods, integrated environments, software process | CASE, spiral model, COCOMO, INTERFORM, integrated environments, the Prentice Hall book. |
| 1990–2000 | Objects and standardization | OOA/OOD, design patterns, UML, components, middleware, CMM. |
| 2001–2010 | Agile and the web | Agile Manifesto, XP, Scrum, open source, continuous integration, SaaS. |
| 2010–2020 | DevOps and cloud | Continuous Delivery, microservices, containers, Kubernetes, SRE, DevSecOps. |
| 2020–present | Generative AI and supervised engineering | Copilot, large language models, software agents, verification, security, governance. |
Internal links
-
Software Engineering
The overview page of my research in the field. -
Program portability (1974–1979)
The first direction through which I entered the problem of software as a transferable artifact. -
Order in Chaos. Software Engineering and
Architectures on Sand (1980–1989)
The decade of the abstract machine, the interform, and the INTERFORM project. -
The model of software design
The abstract machine and progressive refinement as a model of design. -
The concept of interform
Intermediate forms, facets, and levels of representation of the software product. -
The INTERFORM project
A CAD environment for program development. -
Integrating Tools for Software Development
The synthesis published by Prentice Hall in 1992. -
Chronology of Artificial Intelligence, 1943–2025
The parallel page on the evolution of AI, especially useful for the final section on generative AI.
Indicative bibliographic landmarks
- Peter Naur, Brian Randell (eds.), Software Engineering: Report on a Conference sponsored by the NATO Science Committee, Garmisch, 1968, published in 1969.
- J. N. Buxton, Brian Randell (eds.), Software Engineering Techniques, report of the NATO conference in Rome, 1969.
- Edsger W. Dijkstra, “Go To Statement Considered Harmful”, Communications of the ACM, 1968.
- Winston W. Royce, “Managing the Development of Large Software Systems”, 1970.
- David L. Parnas, “On the Criteria To Be Used in Decomposing Systems into Modules”, 1972.
- Frederick P. Brooks Jr., The Mythical Man-Month, 1975.
- Barry W. Boehm, Software Engineering Economics, 1981; “A Spiral Model of Software Development and Enhancement”, 1988.
- Luca Dan Șerbănați, papers on the abstract machine, interform, CAD/CAM, and INTERFORM, 1981–1989.
- Luca Dan Șerbănați, Integrating Tools for Software Development, Prentice Hall, 1992.
- IEEE Computer Society, Guide to the Software Engineering Body of Knowledge (SWEBOK), successive versions, including v4.0.
- Manifesto for Agile Software Development, 2001.
- DORA reports on DevOps and AI-assisted software development, 2024–2025.