DevOps is the greatest innovation in software production today. But DevOps is only the latest in a long series of changes over the past several decades that have revolutionized the way software is written, tested and delivered.
This article discusses the watershed moments and big innovative ideas in the history of software delivery, starting with the early days of coding and moving through to the DevOps era of today.
The land before time-sharing
To start, let’s examine what software production looked like in elder days—by which I mean the 1940s, 1950s and 1960s. These were the earliest decades of computer programming. They were so early in the history of computing that time-sharing systems, which are fundamental to the way we program today, had not yet emerged.
Back then, most code was tightly bound to the particular computer it ran on, with the result that software was not portable. In order to get a program to work, you had to know a lot about the intricacies of the hardware you were working with. This meant programmers also had to be expert admins. This was an era when being a “full-stack” developer was taken to the extreme.
Under these conditions, software production teams were small. It was difficult to manage large teams of developers when narrow, specific skillsets were necessary to produce software for a particular machine. But that slowly changed as computing became something that interested the public at large, rather than just researchers.
The big system era
By the late 1960s, computer hardware had become more affordable and more valuable in commercial settings. This change helped spawn the introduction of new software platforms, such as the Multics and Unix operating systems. These systems were designed to be portable, and to accommodate a large range of user scenarios.
Writing these large systems required a large software production team. Consequently, organizations did what seemed only natural: They threw more programmers at software production in the hope of completing bigger projects successfully.
This approach didn’t necessarily work well, however, which led to…
Fred Brooks and the Mythical Man-Month
In 1975, computer scientist Fred Brooks published The Mythical Man-Month. The book was a critique of the software engineering practices of the time. Brooks believed that most projects were too large, too disorganized and subject to chronic delays due to ever-changing goals and mis-estimates of the time it would take to complete a given task.
One of the central arguments of Brooks’s book was that throwing more programmers at a software project would not facilitate faster completion of the project. Instead, it would lead to diminishing returns, since larger teams are harder to manage efficiently.
Brooks advocated for small, closely managed software projects. He said development teams should set limited goals, avoid feature bloat, and take their time—because, as Brooks noted at the beginning of the book, good software, like good food, takes time to produce.
The open source revolution
The Brooks mantra governed the way software was produced until the 1990s. What changed then was the introduction of the Linux kernel, which showed that it was possible to produce complex software using a large, loosely organized team of programmers.
In other words, the Linux community helped to pioneer what Eric S. Raymond, during a conference presentation, called the “bazaar” mode of software development. (That moment eventually morphed into a book, The Cathedral and the Bazaar.) Whereas Brooks had advocated for a “cathedral”-style approach to production, in which code was carefully written and tested before it was delivered, the Linux developers pushed software updates out early and often. In many cases, they relied on their users to find bugs once the software was already delivered. That was the total opposite of what Brooks had proposed.
(Incidentally, it was also the opposite of what earlier free software projects, namely GNU, had done. As I argue in my forthcoming book For Fun and Profit: A History of Free and Open Source Software—yes, this is a shameless plug—one of the big differences between the GNU and Linux communities early on was that the former clung to the Brooks mantra of software delivery, whereas Linus Torvalds and his followers took a quick-and-dirty approach, which ended up working better for them.)
Of course, not everyone adopted the open source model of software delivery. But even closed source projects were influenced by open source innovations in many ways. For example, closed source companies had to adopt faster release schedules in order to placate users who were supporting open source and had become accustomed to rapid updates.
GitHub and massive collaboration
At first, bazaar-style development projects like Linux relied on clumsy communication tools for collaboration between developers. Programmers would share and merge code using email, or, later, version control systems like CVS and Subversion.
That approach worked well enough for relatively small teams of professional programmers. But what if you wanted to build software in a massively collaborative way? How could you welcome contributions from anyone, without a vetting process? How could you make it easy for everyone to share code publicly, even with people without accounts on your version control system?
That’s what the advent of GitHub helped to do. By facilitating mass collaboration on open source projects, and making it easy for anyone to share and manage source code publicly, GitHub helped to usher in a new era of innovation in the way software was produced.
Granted, there are plenty of software projects that don’t use GitHub. (There are also alternatives to GitHub.) But GitHub has exerted a wide-reaching influence across the software world. For example, the concept of public source code repositories has arguably influenced the way Docker container images are shared today through public registries.
The DevOps revolution
And now we arrive at the present. While DevOps may seem like a radically new approach to software development, it actually just builds on the various innovations described above.
DevOps expands on Brooks’s teachings by encouraging efficient communication between all people responsible for software delivery. While many of Brooks’s ideas are no longer in vogue, the importance of effective communication was one principle that Brooks emphasized that is highly relevant to DevOps.
DevOps also encourages open, flexible modes of collaboration that are similar to those the Linux community helped to make popular. In a DevOps workflow, code is written, tested and delivered continuously. No one part of the team exerts centralized control over the process.
And DevOps, of course, is tightly entwined with technologies like Docker, which are all about making software easily shareable through public repositories.
What will be the next big innovation in software delivery? I’m an historian, not a fortune-teller, so that’s a question I’ll decline to answer. But if the past serves as a guide, it’s a safe bet that whatever comes next will represent an incremental expansion upon the changes described above.
