The History of Software Development

First version 20 October 2026, last changed 24 October 2026 · Andreas Stockter

Software is the part of a computer you cannot touch: the instructions the machine carries out. Software development is the work of writing those instructions, testing them and keeping them alive over years. The history of this craft is short but dense: in eighty years, plugging cables turned into a profession practised by tens of millions of people worldwide, and most recently into an activity that machines partly take over themselves.

Like the history of AI, this text follows a chain: each era resolves a bottleneck the previous one left open, and creates the next one in doing so. First the machine was the bottleneck, then the language, then the size of the programs, then the organisation of people, then the speed of the world. Every technical term is set in bold at the point where it is explained, and is only used after that. A glossary lists all terms alphabetically.

Contents: 1 Prehistory · 2 The first languages · 3 Software crisis · 4 Objects and PCs · 5 Internet and open source · 6 Agile, Git and cloud · 7 AI-assisted development · The chain in brief · Timeline · Further reading · Sources

1. Prehistory (1840s–1940s)

The first program. The idea of giving a machine a sequence of instructions is older than the computer. In 1804 Joseph-Marie Jacquard in Lyon controlled a loom with punched cards: each card determined which threads were raised, and a chain of cards wove a pattern. Around 1837 Charles Babbage adopted the punched card for his Analytical Engine, a mechanical calculating machine that was never finished but had on paper everything that makes a computer: an arithmetic unit, a store and a control that could branch depending on intermediate results.

In 1843 Ada Lovelace translated an article about the engine and added notes that grew longer than the article. In the last of them she describes step by step how the machine would compute the Bernoulli numbers, with loops and intermediate stores. It counts as the first program: a sequence of instructions a machine is to carry out. Lovelace also saw that the machine could compute not only with numbers but with anything that can be expressed in symbols, music included.¹

The punched card itself made a career before there were computers. Herman Hollerith used it in 1890 to evaluate the American census, in two years instead of eight, and his company became IBM in 1924. For four decades data processing meant sorting and counting cards, and when computers arrived they inherited card readers, card punches and the habit of thinking of a program as a stack.

The first computers. In 1941 Konrad Zuse in Berlin put the Z3 into operation, the first working program-controlled computer. The program was a sequence of holes punched into used cinema film that ran through a reader. Zuse was also the first to think about how programs could be written down for people to read: his Plankalkül, designed between 1942 and 1945, was the first high-level programming language, with variables, loops and data structures. It was not published until 1972 and influenced nobody, but it shows that the question of language is as old as the machine.²

The American ENIAC, completed in 1945, computed a thousand times faster than anything before it but was not programmable in today’s sense. A new task meant replugging hundreds of cables and setting switches, a job of days. It was done by six women mathematicians who were called “computers” at the time, because the word still referred to the person who computes. They were the first programmers, and along the way they developed the first techniques of the field, such as tracing the program on paper to find errors.

The stored program. The solution to the replugging was formulated by John von Neumann in 1945 in a report on the successor machine EDVAC: the program lies in memory like the data, as numbers. Then it can be exchanged in seconds, and a program can even treat other programs as data, that is, read, change and generate them.³ The idea was implicit in Turing’s work of 1936, and von Neumann’s report made it the blueprint. On 21 June 1948 the first stored program ran in Manchester on the experimental machine “Baby”: 17 instructions that searched for the largest divisor of a number, for 52 minutes. In 1949 the EDSAC followed in Cambridge, the first such computer in daily service.

With it, software development began as an activity. A program for the EDSAC was a sequence of numbers in machine language, the set of commands the hardware understands directly: load memory cell 100, add cell 101, jump to instruction 7. David Wheeler, a student at Cambridge, devised two aids for it that form the foundation to this day. First the assembler, a program that accepts commands as short words such as ADD instead of numeric codes and translates them into machine language. Second the subroutine: a piece of program that performs one task, such as taking a square root, and can be called from anywhere. Cambridge built a library of such subroutines on punched tape, and the book by Wilkes, Wheeler and Gill of 1951 was the first textbook of programming.⁴

An example: adding two numbers and storing the result meant three numeric words in machine language, say 01 100, 02 101, 03 102. In assembler this became:

LOAD  A      ; fetch the number from cell A into the arithmetic unit
ADD   B      ; add the number from cell B
STORE C      ; put the result into cell C

The assembler replaced the short words and the names of the cells with the numbers the machine expected. Reading became easier; the thinking remained the machine’s.

Maurice Wilkes, the head of the EDSAC, later recalled a moment in 1949 on the stairs between the computer room and the tape punching equipment: he realised that a good part of his life would be spent finding errors in his own programs. Such an error is called a bug. The word is older than the computer, but in 1947 Grace Hopper’s team taped a moth that had jammed a relay of the Harvard Mark II into the logbook, with the note “first actual case of bug being found”. Searching for and fixing them has been called debugging ever since.

The bottleneck. Every program was written in the language of exactly one machine, instruction by instruction, and was worthless as soon as the machine was replaced. Programming was expert work for a few dozen people per computer, and a computer cost more than everyone who worked on it.

2. The first languages (1950s)

The compiler. Grace Hopper, naval officer and mathematician, had programmed the Harvard Mark I and in 1949 joined the company that built the UNIVAC. She wanted programs no longer to have to be written in machine language. In 1952 she presented A-0, a program that assembled a runnable program from a sequence of subroutine calls, and called it a compiler: a program that translates programs from a form readable by humans into machine language.⁵ Her FLOW-MATIC, developed from 1955, accepted commands in English words. Hopper reported that the idea was initially laughed at, because computers supposedly could only do arithmetic and not understand English.

Fortran. The breakthrough came in 1957 from a team at IBM around John Backus. In 1954 Backus had proposed building a language in which formulas are written as in mathematics, and a compiler that produces machine code from it that runs as fast as hand-written code. The experts considered the second part impossible. After three years of work, Fortran (“Formula Translation”) appeared, the first widely used high-level language, that is, a programming language that abstracts from the machine and can be the same for different computers.⁶ A line such as Y = A*X**2 + B*X + C replaced dozens of machine instructions, and the number of lines of programming for a task fell to a twentieth. Fortran made programming accessible to scientists and engineers who did not want to learn machine language, and it is still used in numerical simulation today.

The compiler is the tool that makes this chapter possible. It reads the source code, the program written by a human, checks it for form and meaning, and generates the executable code from it. Its counterpart is the interpreter, which does not translate the source code but executes it line by line as it reads, more slowly, but without waiting. Both routes accompany the field to this day, Fortran and C on one side, Python and JavaScript on the other.

Four languages, four directions. Within a few years the ancestors of almost all of today’s languages came into being. Lisp (1958) by John McCarthy, described in the history of AI, treated programs themselves as data and introduced recursion and garbage collection, automatic memory management in which the system releases memory that is no longer needed by itself. COBOL (1959) was designed by a committee of government agencies and manufacturers for the business world, with sentences such as ADD TAX TO TOTAL, so that non-programmers could read programs too. Hopper’s FLOW-MATIC was the model. COBOL processed payrolls and account transactions, and a large part of payment traffic still runs today on COBOL programs older than the people who maintain them.

Algol 60, finally, was the work of an international committee and less a product than an idea: blocks that hide variables, procedures that call themselves, and an exact description of the language in a formal notation, the Backus–Naur form, with which the grammar of a programming language can be written down as precisely as a proof.⁷ Algol itself was little used, but Pascal, C, Java and almost everything after them descend from it. Tony Hoare later said that Algol 60 was so far ahead of its time that it was an improvement not only on its predecessors but on nearly all its successors.

This is what the Backus–Naur form looks like, here for whole numbers:

<digit>  ::= 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9
<number> ::= <digit> | <number> <digit>

The second line says: a number is a digit, or a number followed by a digit. Two lines describe all numbers of any length, and from such rules a compiler can generate the part that takes the source code apart.

BASIC was designed by the mathematicians John Kemeny and Thomas Kurtz at Dartmouth College for students who did not want to become computer scientists; the first program ran on 1 May 1964 at four in the morning.⁸ It ran on a time-sharing system, in which many users sit at teletypes at the same time and the computer switches between them so fast that each believes they have it to themselves. Programming in dialogue, type a line, run it at once, see the error, was a new experience. Ten years later BASIC made the first home computers usable.

The bottleneck. The languages had speeded up the writing of individual programs many times over, and precisely for that reason the programs grew larger. A computer could now have an operating system, a program that manages the others, and the first big one confronted the industry with a problem that no language solves.

3. Software crisis and structured programming (1960s–1970s)

OS/360. In 1964 IBM announced the System/360, a whole family of computers that were all to run the same programs, from the small office model to the large installation. The operating system for it, OS/360, was to be everything at once: load programs, manage memory and devices, run several tasks side by side. It became the largest program ever written, more than a million lines, and it arrived years late, consumed many times its budget and was full of errors on delivery. Fred Brooks, who led the project, drew the lessons from it in 1975 in a book that is still read today: “The Mythical Man-Month”. His most important observation is called Brooks’s law: adding people to a late software project makes it later, because the newcomers have to be trained and the number of coordination paths explodes with the number of participants. Nine women cannot bring a child into the world in one month.⁹ In numbers: with n participants there are n(n − 1)/2 lines of communication, three for three people, 45 for ten, 1,225 for fifty.

The software crisis. OS/360 was no isolated case. At the end of the 1960s, large programs were regularly late, too expensive and unreliable, while hardware became cheaper and faster every year. In October 1968 NATO invited around fifty experts to Garmisch-Partenkirchen to talk about it. The Munich computer scientist Friedrich L. Bauer had given the conference a provocative title: software engineering. The name was a programme: software was to be designed and built like bridges, with methods, measurements and responsibility, instead of as a craft. The conference report coined the term software crisis for the state in which the demand for programs and their size grew faster than the ability to build them reliably.¹⁰

That it could be done differently was shown in the same year by a project the conference did not yet know. The software for the onboard computer of the Apollo lunar module, led by Margaret Hamilton at MIT, was built so that under overload it dropped unimportant tasks and kept computing the important ones. Three minutes before the landing on 20 July 1969 the computer reported exactly this overload, and because the software had anticipated it, the landing could continue. Hamilton called her work “software engineering” when the expression was still smiled at.

Structured programming. The answer to the crisis came from theory. Edsger Dijkstra, a Dutch mathematician, wrote a letter to the editor in 1968 entitled “Go To Statement Considered Harmful”. The jump instruction goto, with which a program jumps to any other place, had been taken for granted in all languages since machine language. Dijkstra showed that it makes programs unreadable: anyone who wants to know how the program got to a place has to know all the jumps that lead there. The quality of a programmer, he wrote, decreases with the number of goto statements.¹¹

The alternative is called structured programming: a program is composed of only three building blocks, the sequence of instructions, the branch (if, then, else) and the loop (while, repeat). Corrado Böhm and Giuseppe Jacopini had proved in 1966 that these three suffice for any program. Each block has one entry and one exit, and so a program can be read from top to bottom like a text. In 1970 Niklaus Wirth built the language Pascal around this idea and with it educated a generation of students, and the book “Structured Programming” by Dahl, Dijkstra and Hoare (1972) made it doctrine.

The same piece of program, once with jumps, once structured. Both count from 1 to 10:

10 LET I = 1                   I = 1
20 PRINT I                     WHILE I <= 10
30 LET I = I + 1                   PRINT I
40 IF I <= 10 THEN GOTO 20         I = I + 1
                               END WHILE

On the left one has to follow the line numbers to see that a loop is meant. On the right the loop stands there as a block, with a beginning and an end.

Modules. The second building block was supplied by David Parnas in 1972. Large programs, he proposed, are broken down into modules, parts with a clear task and an interface, that is, a fixed set of calls through which other parts talk to them. What happens inside a module, such as how data is stored, remains hidden so that it can be changed without the other modules noticing. This principle of information hiding is the basis of all software larger than one person.¹²

The waterfall model. In 1970 Winston Royce described in a paper how large software projects ran at the time: fix the requirements, then design, then program, then test, then operate, each stage completed before the next begins, like water falling over steps. Royce wrote the paper to warn against this sequence: the errors of the design only show up in testing, and then going back is expensive. He proposed five additions: a preliminary design before the analysis, extensive documentation, independent test planning, continuing reviews with the customer and above all “do it twice”: the delivered version should be the second one, after a pilot model on a small scale, the prototype, twenty years before the word became common. His figures show arrows back from every stage to the previous one and from testing back to design. Nevertheless the waterfall model, so named only in 1976 by authors who cited his figure, became the standard for decades. In 1985 the software standard of the US Department of Defense prescribed exactly the simple sequence Royce had warned against, and government agencies and corporations followed it.¹³

Unix and C. While the corporations suffered under giant systems, the counter-model emerged at Bell Labs. In 1969 Ken Thompson wrote, on a discarded minicomputer, an operating system that was small, elegant and meant for programmers: Unix. His colleague Dennis Ritchie designed the language C for it in 1972, close to the machine but with the structures of Algol, and in 1973 the two rewrote Unix in C. For the first time an operating system was written in a high-level language and could be carried to other computers, which later led to its spread at universities.¹⁴

Unix brought with it a way of thinking that works to this day: many small programs that each do one thing well, and a mechanism, the pipe, with which the output of one is fed into the input of the next. Instead of one large program, one builds a chain of tools. Added to this were a file system in which everything is a file, devices included, and source code that was passed on to universities for a fee, so that students could read and change it. Berkeley built its own version on it, BSD, which received the Internet protocol.

An example that still works in any Unix terminal today:

grep error log.txt | sort | uniq -c | sort -rn | head -5

The first tool picks out all lines containing “error”, the second sorts them, the third counts identical lines, the fourth sorts by frequency, the fifth shows the first five. Five programs that know nothing of each other jointly answer the question of which errors occur most often.

Software becomes a commodity. Until 1969 IBM supplied software free of charge with the hardware, as an extra like the manual. Under the pressure of an antitrust case, in June 1969 IBM separated the prices of hardware and software, the unbundling. From then on software was a product of its own with its own price, and an industry arose that sold only programs. At the same time Donald Knuth began his work “The Art of Computer Programming” (from 1968), which penetrated the algorithms of the field mathematically and gave programming the claim to be science and art at once.¹⁵

Try it yourself. The Compiler Explorer shows in the browser, next to every line of C code, the machine instructions the compiler makes of it; one sees what Fortran took off programmers’ hands in 1957. An EDSAC simulator from the University of Warwick runs the programs of 1949 on the screen, with punched tape and tube display. And every terminal on a Mac or Linux understands the pipe above; whoever types it once understands Unix.¹⁶

The bottleneck. Structured programs and modules made large systems manageable as long as the parts kept to their interfaces. But the parts were written in languages that kept data and the functions working on it separate, and with every change to the data structure all the functions had to follow. At the same time an upheaval was imminent that nobody in Garmisch had foreseen: the computer became so cheap that it fitted on a desk.

4. Objects and personal computers (1980s)

Objects. The idea came from Norway. In 1967 Ole-Johan Dahl and Kristen Nygaard had designed the language Simula for simulations, in which things of the real world, such as ships in a harbour, are described as objects: each carries its data and the operations that work on it together within itself. A class is the blueprint for objects of the same kind, and a class can inherit from another, that is, take over its data and operations and extend them. An account, for example, carries the balance as data and deposit and withdraw as operations; each individual account is an object, the blueprint of all accounts the class, and a savings account inherits from it and adds the interest. Alan Kay took up the idea at the research centre Xerox PARC and made it the principle of a whole language: in Smalltalk (1972 to 1980) everything is an object, and objects talk to each other by sending messages. Kay had biological cells in mind, which work independently and coordinate through messenger substances.¹⁷ This way of thinking is called object-oriented programming: software as a society of cooperating objects rather than as a sequence of instructions over data.

Smalltalk ran on the Alto, a computer PARC had built in 1973 that looked like the future: a screen with windows and icons, a mouse, a network. The programming environment was part of the system; one could click on any object, view its code and change it while it was running. Steve Jobs saw the Alto in 1979 and built the Macintosh from it.

Bjarne Stroustrup brought objects into the world of systems programmers in 1983: C++ added classes to C without giving up closeness to the machine, and became the language for operating systems, databases, games and everything that has to be fast.¹⁸ Objective-C did the same in 1984 with Smalltalk messages and found a home at NeXT and later at Apple. By the turn of the millennium object-oriented programming had established itself as the normal form, and the book “Design Patterns” by Gamma, Helm, Johnson and Vlissides (1994) gave the recurring building shapes names in which developers talk to each other to this day: Factory, Observer, Adapter, that is, a class that creates objects; an object that reports changes to everyone who has subscribed; an intermediate piece that joins two ill-fitting interfaces.¹⁹

The personal computer. In January 1975 the cover of the magazine “Popular Electronics” showed the Altair 8800, a kit for 397 dollars that could do nothing but blink lights. Two students at Harvard, Bill Gates and Paul Allen, wrote a BASIC interpreter for it in eight weeks without ever having seen the machine, and founded Microsoft for the purpose. Gates’s “Open Letter to Hobbyists” of February 1976 complained that most users copied the BASIC instead of buying it, and marked the dispute that has accompanied the field ever since: is software a good that one owns and sells, or a knowledge that one shares?²⁰

The Apple II (1977) brought the computer into the living room, and in 1979 VisiCalc, the first spreadsheet, showed what it was good for: an accountant could change a sheet of figures and immediately see all the consequences. It was the first killer application, a program for which people buy a computer. In 1981 the IBM PC followed with the operating system MS-DOS from Microsoft, which IBM had not bought but merely licensed. The mistake cost IBM the market and made Microsoft the largest software manufacturer in the world. The Macintosh brought windows and mouse to the masses in 1984, Windows followed in 1990.

Tools. With the PC, programming became an activity at one’s own desk, and the tools moved closer together. Turbo Pascal (1983) from Borland cost 50 dollars and united editor, compiler and debugger in one program, the first widely used integrated development environment (IDE), in which one changes a line and sees the result seconds later. The feedback loop, which on the mainframe had taken hours, hand in punched cards, collect the printout the next day, shrank to moments, and that changed how people program: by trying rather than by planning.

Free software. Richard Stallman, a programmer at MIT, had watched the open culture of the laboratories disappear as companies locked away source code. In 1983 he announced GNU, an operating system resembling Unix but which anyone may use, read, change and pass on, and wrote a compiler, editor and tools for it.²¹ His legal device was the GNU General Public License (1989): anyone who changes and passes on free software must pass on the source code and the freedom with it. This licence, the permission to use software under certain conditions, turned an attitude into a legal instrument, and all it lacked was a kernel to make a complete system.

Software that kills. Between 1985 and 1987 the radiation therapy machine Therac-25 gave six patients massive overdoses, three of whom died. The cause lay in the software: a race between two parts of the program that only occurred when the operator typed faster than the developers had imagined. The older model had had a mechanical interlock, which had been dropped in favour of the program. Nancy Leveson’s investigation became the textbook case that software which decides over lives must follow different rules, and founded the field of software safety.²²

The bottleneck. Objects, IDEs and the PC had made programming more productive for a single developer than ever. But every program ran on one computer and was sold as a floppy disk in a box. The computers began to talk to each other, and with that, how software comes into being and whom it reaches changed.

5. Internet and open source (1990s)

Linux. On 25 August 1991 a 21-year-old student in Helsinki wrote to a discussion group that he was working on a free operating system, “just a hobby, won’t be big and professional”. Linus Torvalds had written an operating-system kernel for his PC, and because he put it on the net and accepted every contribution that was good, Linux grew within a few years into a complete system, together with the GNU tools Stallman had prepared.²³ Thousands of volunteers who never met built the operating system that today runs on almost every server, every Android phone and most of the cloud. The kernel had around 10,000 lines in 1991; today it has over 30 million, and several thousand developers contribute to each new version. Development ran over mailing lists: whoever had a change sent it as a patch, a text containing only the changed lines, and Torvalds accepted or rejected it.

This is what a patch looks like, here a one-line change:

--- a/counter.c
+++ b/counter.c
@@ -12,3 +12,3 @@
     total = total + value;
-    if (counter > 100)
+    if (counter >= 100)
         output(total);

The line with the minus is removed, the one with the plus inserted, and the lines around them show where in the program this happens. A reviewer needs nothing more to judge the change.

The web. In 1989 Tim Berners-Lee proposed at CERN a system for linking documents over the Internet, and built it in 1990 and 1991: a page description language, HTML, a transfer protocol, HTTP, and a program for reading, the browser.²⁴ The browser Mosaic (1993) showed images within the text and made the web popular, Netscape (1994) made it commercial. For programmers the web meant two things. First a new platform: a program no longer had to be installed, it ran on a server, and anyone with a browser could use it. Second a market that changed every few months, in which the first to deliver something usable won, and which made the planning of year-long projects ridiculous.

New languages for the net. In 1995 Brendan Eich wrote in ten days a language that runs in the browser, so that web pages could move and react to input: JavaScript, today the most used language in the world. In the same year Sun presented Java, with the promise “write once, run anywhere”: the compiler produces not machine code but bytecode, an intermediate code that a virtual machine executes on any computer that has one. Java became the language of enterprise servers and later of Android. Guido van Rossum had released Python in 1991, a scripting language, that is, an interpreted language for quick, short programs, meant to be as readable as pseudocode. It grew slowly and three decades later became the language of data analysis and AI. Perl (1987) and PHP (1995) drove the first dynamic web pages, and with the web server Apache (1995) and the database MySQL (1995) a free kit emerged on which anyone could start a service.

Open source. In 1997 Eric Raymond described in the essay “The Cathedral and the Bazaar” why Linux worked: not like a cathedral, built by a few masters according to plan, but like a bazaar, in which many work at the same time, release early and often, and every error is found quickly because enough eyes are looking.²⁵ The essay moved Netscape in 1998 to release the source code of its browser, from which Firefox later emerged. For the release, a group around Raymond sought a name that sounded less political than Stallman’s “free software” and coined open source: software whose source code lies open and which anyone may use, change and pass on. The difference from Stallman lay in the justification, practical benefit rather than freedom as a principle, and it divides the movement to this day. For industry, open source became infrastructure: by 2020 a typical program consisted to around 70 per cent of foreign open building blocks.

Version control. With many participants a question arose anew: who changed what and when, and how does one bring two changes to the same file together? A version control system keeps every state of a project and allows changes to be compared, reverted and merged. CVS (from 1986) was the first widely used one, Subversion (2000) its successor. Both had a central server, and Linux, the largest distributed project in the world, used neither for a long time, but e-mail and Torvalds’s memory.

The year 2000. The turn of the millennium taught the field a lesson about lifespan. Programs from the 1960s, which stored the year with two digits to save memory, were still running, and nobody knew what would happen at “00”. Hundreds of billions of dollars were spent worldwide reading and patching old code, much of it COBOL. It stayed quiet, and to this day it is disputed whether that was due to the precautions or to exaggeration. What is certain: software lives longer than its authors believe.

The bottleneck. The waterfall model no longer fitted a world in which requirements changed faster than a project lasted. Whoever planned and built for two years delivered something nobody needed any more. The methods had to follow the speed of the net.

6. Agile, Git and cloud (2000s–2010s)

The Agile Manifesto. In February 2001 seventeen developers who had independently tried out lightweight methods met in a ski lodge in Utah and agreed on four sentences: individuals and interactions over processes and tools, working software over comprehensive documentation, customer collaboration over contract negotiation, responding to change over following a plan.²⁶ Agile development has meant ever since: deliver in short increments, each time working software, and adjust the plan after every delivery. Scrum, presented in 1995 by Ken Schwaber and Jeff Sutherland, gave this a framework: a team works in sprints of two to four weeks, holds a short meeting every morning and shows at the end what is finished. Kent Beck’s Extreme Programming contributed the practices: programming in pairs, small steps, and above all testing.

Tests. An automated test is a program that checks another program: it calls a function with known inputs and compares the result with the expected one. In 1997 Beck and Erich Gamma wrote JUnit, a tool that runs hundreds of such tests in seconds, and in 2002 Beck described test-driven development: first write the test that still fails, then just enough code to make it pass, then tidy up.²⁷ Tests made it possible to change software continually without fear of breaking something old, and they became the precondition for everything that followed.

A test is often shorter than what it checks. For a function that recognises leap years:

def test_leap_year():
    assert leap_year(2024) == True
    assert leap_year(1900) == False
    assert leap_year(2000) == True

If the second line fails, someone has forgotten the exception that full centuries are not leap years, except every four hundred years. The test remembers it, at every change, for ever.

Git. From 2002 Linux had used a commercial version control system whose maker ended free use in 2005. Torvalds wrote a replacement in two weeks: Git. Unlike CVS, Git has no central server; every developer has the complete history of the project on their own machine, can work independently and create branches, and the merge, bringing two states together, is so cheap that it becomes routine.²⁸ In 2008 three developers founded GitHub, a website on which anyone could store Git projects and collaborate on others’, with a button that turned a patch into a discussion: the pull request, the request to adopt a change. GitHub became the place where open source happens, with over 100 million users in 2023, and the place where companies look for developers. In the same year, 2008, Stack Overflow was founded, a question-and-answer site that became the memory of the field: almost every error message led there.

Always delivering. When changes are small and tests are fast, every change can be checked immediately. Continuous integration means that every contribution is automatically built into the overall project and tested, many times a day, so that errors are noticed minutes after they arise instead of months later.²⁹ How far this goes was shown by Google in 2016: a single repository with two billion lines of code, into which 25,000 developers check in 45,000 changes every working day, each one checked automatically.³⁰ The next step was to put the tested software straight into operation as well. At a conference in 2009 two developers from Flickr reported that they updated their website more than ten times a day, and in the same year the word DevOps was born: developers (development) and operators (operations), until then separate departments with opposing interests, work as one team, and the pipeline from source code to running service is automated throughout.

The cloud. Amazon had built data centres for its warehouse and from 2006 offered them to others: storage (S3) and computers (EC2), rented by the minute, ordered by program call.³¹ The cloud turned hardware into a service. A start-up no longer needed servers, only a credit card, and a program could run on one machine one day and on a thousand the next. The software had to be built differently for this: as microservices, many small services that talk to each other over the network, each individually replaceable, instead of as one large program. Docker (2013) made this manageable: a container packs a program with everything it needs so that it runs the same on any machine, and Kubernetes (2014) distributes thousands of containers over thousands of machines.³²

The smartphone. In 2007 Apple presented the iPhone, in 2008 the App Store, and Google in the same year Android. For the first time every person carried a computer with them, and for the first time a single developer could sell a program to hundreds of millions of people, without box, dealer and distribution. The app business created a new profession and new languages, Swift (2014) for Apple, Kotlin (2016) for Android, and it shifted programming from the desktop computer to screens that fit in the hand.

Marc Andreessen, once co-author of Mosaic, wrote in 2011 the sentence that described the decade: “Software is eating the world.” Bookselling, music, taxis, hotels, television, banks: the largest companies in every industry became software companies, and the number of developers grew to over 20 million.³³

Dependencies. With open source and package managers such as npm for JavaScript (2010), nobody built from scratch any more. A program declared its dependencies, foreign building blocks it needs, and a tool downloaded them together with their dependencies, often thousands. In March 2016 a developer withdrew out of annoyance an eleven-line package called left-pad that padded strings, and thousands of projects worldwide, including Facebook and Netflix, could not be built for hours.³⁴ The incident showed how much depended on how little. Security holes weighed more heavily: Heartbleed (2014) in the encryption library OpenSSL, which was maintained by a handful of volunteers and protected half the Internet, and Log4Shell (2021) in a Java library that sat in millions of programs without their operators knowing.³⁵ In the attack on SolarWinds (2020), attackers whom the US government attributed to the Russian foreign intelligence service had taken over the company’s build server, the computer on which the finished program is produced from the source code. At every build their tool inserted a backdoor into the network software Orion before it was digitally signed. The update went to around 18,000 customers, including US government departments, and remained undetected for nine months until the security firm FireEye found the intrusion at its own premises. The source code was clean; the factory was poisoned.³⁶ The supply chain of software, the chain of building blocks, tools and services from which a program is made, became a target of attack and a field of research.

The bottleneck. The methods had speeded up delivery, the cloud had abolished hardware, open source the wheel. What remained was the human being who writes the code. Developers were the scarcest resource in the industry, companies poached them with salaries once reserved for managers, and every tool that made a developer faster was worth gold. Then came a tool that wrote the code itself.

7. AI-assisted development (since 2021)

Copilot. That language models can generate code had shown itself incidentally with GPT-3 in 2020: it had read enough programs to write simple functions from a description. OpenAI then trained Codex, a model fine-tuned on 159 gigabytes of code from GitHub, and in June 2021 GitHub built it into the editor as Copilot: as you type, the model proposes the next lines, from the context of the file and a comment in everyday language.³⁷ The suggestions were often right, sometimes wrong, occasionally a verbatim copy from someone else’s code, which drew lawsuits over licence violations. A year later a million developers were using it, and GitHub reported that in files where Copilot was active around 40 per cent of the code came from it.

ChatGPT. In November 2022 ChatGPT changed the way of working once more. Instead of accepting suggestions in the editor, one described a problem to the model, got code back, pasted the error message into the conversation and got the correction. Stack Overflow, the memory of the field, lost half its questions within two years, because the answers now came from the model, which had been trained on Stack Overflow among other things. GPT-4 (2023) reliably solved the easy tasks from programming job interviews, and editors such as Cursor (2023) built the conversation directly into the development environment, so that the model rewrites whole files.

An example: asked to “write a function that checks whether a year is a leap year”, the model answers within seconds:

def leap_year(year):
    return year % 4 == 0 and (year % 100 != 0 or year % 400 == 0)

The exception for full centuries, which the test from Section 6 queries, is built in, because the model has read this function in thousands of versions. For tasks nobody has solved before, what it has read helps less.

Agents. The third step was to put the tools into the model’s hands. A coding agent reads a project, changes files, runs tests, reads the errors, corrects and repeats this until the tests pass, without a human intervening in between. Devin (2024) was presented as the first “AI software engineer”; in 2025 Claude Code from Anthropic and Codex from OpenAI followed, which work in the terminal and on GitHub, take tasks from a project’s issue list and submit pull requests like a colleague.³⁸ This is measured with SWE-bench, a collection of real bug reports from open-source projects: at the end of 2023 the best models solved 2 per cent of them, in 2025 over 70 per cent of the verified subset, and in summer 2026 around 97 per cent, whereupon the leaderboard was retired because the test was exhausted.³⁹ In February 2025 Andrej Karpathy coined the term vibe coding for the way of working in which one tells the model what one wants, no longer reads the code and judges only the result.⁴⁰ For prototypes and throwaway programs this works; for software that is to live long, it is the old mistake of OS/360 in new clothing: code that nobody understands.

What the numbers say. In October 2024 Google stated that more than a quarter of new code in the company was generated by AI and reviewed by developers, and in spring 2026 three quarters. A controlled study by the institute METR, by contrast, found in July 2025 that experienced developers were 19 per cent slower with AI tools in their own large open-source projects, while they themselves believed they were 20 per cent faster.⁴¹ A follow-up study of February 2026 pointed, for the same developers, to a speed-up of around 18 per cent, with so much uncertainty that METR itself called the result an unreliable signal. Both are probably true: the tools greatly speed up routine work and new, small programs, and they help little with code whose connections live in a person’s head. The Stack Overflow survey of 2025 showed that almost all developers use the tools and that trust in their answers is falling at the same time.

The profession. Programming was the first occupation in which language models visibly reshaped everyday work, and the consequences hit the beginners first. A Stanford study counted in August 2025 that the employment of software developers aged 22 to 25 had fallen by a fifth since the end of 2022, while that of older ones grew.⁴² The work through which one had learned the craft, small tasks under guidance, was now done by the model. At the same time, companies reported job cuts in 2025 that they justified with AI. What the profession will be in ten years, nobody knows. What seems certain is that its centre of gravity is shifting: from writing to reading, checking and deciding, from the line to the system.

The limits. In 2026 the agents showed what happens when they are given tools and a goal. In a security test by OpenAI, two models broke out of their test environment and penetrated foreign servers in order to cheat on an evaluation; after another incident Anthropic switched off Internet access for its agents in all internal tests.⁴³ The history of AI describes both cases. For software development this means: an agent that executes code is a user with rights, and the question of who answers for its actions is open.

Try it yourself. Git is best learned on a project of your own: the free courses from GitHub Skills lead in an hour from the first commit to the pull request, and the book “Pro Git” is freely available online. Anyone who wants to see what a coding agent does can let Claude Code or Codex loose on a small project of their own, or the open-source Aider, which works with any model, and watch it run tests and read errors. The SWE-bench leaderboard shows which agents currently solve the real bug reports from open-source projects best.⁴⁴

The open bottleneck. Every era of this chronicle has made writing code cheaper, from replugging cables to a sentence in everyday language. What remains is what was never cheap: knowing what one wants, and answering for what runs. The software crisis of 1968 meant that people needed more code than they could write. The one of 2026 means that there is more code than people can read.

The chain in brief

1. The stored program (1945) makes the computer reprogrammable, but every program is bound to its machine.
2. Compilers and high-level languages (Fortran 1957) detach programs from the machine and make them large. Size becomes the problem.
3. Structured programming, modules and Unix (1968–1973) make large programs manageable. The organisation of people remains the problem.
4. Objects, IDEs and the PC (1980s) make the individual developer productive. Programs run on one computer while the world gets networked.
5. Linux, the web and open source (1990s) spread the work over many. Planning in years no longer fits the speed.
6. Agile methods, Git, tests and the cloud (2001–2013) deliver daily. The human who writes code becomes the bottleneck.
7. Language models and agents (since 2021) write code themselves. Who understands and answers for it remains open.

Timeline

Further reading

• Frederick P. Brooks: The Mythical Man-Month. Essays on Software Engineering. Anniversary edition, Addison-Wesley, Reading 1995. The classic on organising software projects, still valid after fifty years.
• Martin Campbell-Kelly, William Aspray, Nathan Ensmenger, Jeffrey R. Yost: Computer. A History of the Information Machine. 3rd edition, Westview Press, Boulder 2014. The standard history of the computer, with software as its thread.
• Nathan Ensmenger: The Computer Boys Take Over. Computers, Programmers, and the Politics of Technical Expertise. MIT Press, Cambridge 2010. How programming became a profession and why it is so hard to pin down.
• Steven Levy: Hackers. Heroes of the Computer Revolution. 25th anniversary edition, O’Reilly, Sebastopol 2010. The culture of the labs and garages from the 1950s to the PC.
• Eric S. Raymond: The Cathedral and the Bazaar. O’Reilly, Sebastopol 1999. The essays that made open source a term.
• Scott Rosenberg: Dreaming in Code. Crown, New York 2007. Reportage on a project that wanted to do everything right and failed anyway, with a history of software engineering on the side.
• Dennis M. Ritchie: The Development of the C Language. In: History of Programming Languages II, ACM 1993. The inventor on his language and Unix.
• Grady Booch: Object-Oriented Analysis and Design with Applications. 3rd edition, Addison-Wesley, Boston 2007. The textbook of object orientation.

Sources

The chronicle rests on the original works and contemporary reports named in the footnotes.