The Three Evolutions of Software Engineering Methods and the Role of DevOps in Modern Software Delivery
This article traces the evolution of software engineering from the 1970s waterfall model through 1990s agile iterations to the 2010s DevOps and continuous delivery movement, explains the expanding delivery loop and collaborative roles, defines DevOps, and discusses practical challenges and ways to overcome them in enterprises.
1. The Three Evolutions of Software Engineering Methods
(1) The 1970s software crisis and the waterfall model
In the 1960s rapid computer adoption outpaced software delivery capabilities; in 1970 Dr. Rayce formally introduced the waterfall development model, which required two implementations to achieve project success.
(2) The 1990s agile and iterative approaches
Despite the waterfall model’s shortcomings highlighted by repeated Chaos Reports, many engineers sought cheaper, faster ways to deliver working software, spawning various agile methods that focused on rapid delivery within long project cycles, while the waterfall model persisted at a finer, iterative granularity.
(3) The 2010s DevOps and continuous delivery
With widespread internet use and massive user‑scale deployments, the tension between development and operations resurfaced, giving rise to the DevOps movement and its continuous delivery framework, while the waterfall model was reduced further to a “requirement‑level” granularity.
2. Software Delivery Loop and Role Collaboration
The evolution described above shifts from a half‑loop delivery to a full‑loop model, expanding collaboration to include operations personnel.
3. What DevOps Is
DevOps, like Agile, lacks a single formal definition; it is a movement that seeks a set of methods and practices to improve collaboration quality and efficiency across roles in the software delivery process, thereby accelerating service delivery.
4. The Enterprise Journey of DevOps Practice
Many teams adopt various practices and see early success, but eventually hit a plateau where further progress stalls or even regresses, as illustrated in the diagram.
5. Why This Journey Occurs and How to Cross the Gap
Viewing problems from multiple perspectives uncovers new leverage points; we must seek a “second‑order” change to break through the plateau.
Finally, you are sincerely invited to attend two DevOps events on November 2 in Shenzhen, where we will discuss my new book “Continuous Delivery 2.0 – Business‑Driven DevOps”.
The preview edition of “Continuous Delivery 2.0” will be released at the two DevOps gatherings.
Signed-in readers can open the original source through BestHub's protected redirect.
This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactand we will review it promptly.
Continuous Delivery 2.0
Tech and case studies on organizational management, team management, and engineering efficiency
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.