Why are people so excited to announce the death of software development paradigms?
“Agile is Dead” is a great clickbait headline. To commemorate the 20th anniversary of the publication of the Manifesto for Agile Software Development, all sorts of pundits came out of the woodwork to announce that Agile was dead. Agile is not the first 20-year-old software development paradigm to be declared dead. COBOL, eXtreme Programming, UML are a few others. Why are people so excited to announce the death of software development paradigms?
The first fax was sent in 1860. The samurai in Japan were not abolished until 1868. That means there was a five-year period when a samurai could have sent Lincoln a fax warning him about his assassination in 1865. The online fax market will be over $1 billion this year – 161 years after the first fax. Some technologies just won’t die.
There are many paradigms in the software development industry that have been declared dead. Some include:
- COBOL (1959)
- Mark IV – First 4GL (1968)
- Structured Analysis & Design (1973)
- Information Engineering (1981)
- Rapid Application Development (RAD) (1991)
- Unified Modeling Language – UML (1995)
- Scrum (1996)
- Extreme Programming (1996)
- Manifesto for Agile Software Development (2001)
At one point or another, all of these approaches have been declared dead.
“Agile is Dead” is one of the quintessential examples of how software development paradigms are declared to be dead. In 2014 Dave Thomas, one of the original 12 signatories of the Agile Manifesto, published an article Agile is Dead (Long Live Agility). This led to many conferences inviting Dave to speak. When you search Google for “Agile is Dead” Dave’s presentation at GOTO 2015 Amsterdam pops up as #1. The presentation is 38 minutes long but well worth your time.
Dave Thomas does a great job of talking about why Agile is Dead and the need to return to Agility. When you look at other software development paradigms you can find the same basic story repeated time and again. The structure of the story is:
All stories begin with the author establishing why they are an authority that you should trust. In Dave’s case, it was simple. He was one of the original twelve people that met in Snow Mass Colorado in 2001 to come up with the Manifesto for Agile Software Development. He published the results at agilemanifesto.org.
This sets the stage for the rest of the story. Dave reiterates the core values of Agile:
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
Dave points out a few things in the contemporary practice of Agile that conflict with its original intentions:
- Agile is an adjective, not a noun. The manifesto was named the Manifesto for Agile Software Development for a reason. The industry that grew up around Agile transformed the adjective agile into the noun Agile. You can’t sell adjectives (“I’ll have a kilo of green please”), but you can sell nouns (“I’ll have a kilo of Agile please”)
- Agile was meant for small teams. The ‘industry’ discovered that the money for Agile training, consulting, and conferences were not in small teams, but large organizations. Hence the need for agile to scale.
- The “industry” uses fear to sell. To sell training, consulting, certifications, etc. the industry uses fear. You need a translator to explain new words, new roles, new ways to measure and ensure you are doing it right. Companies will pay money to assuage their fears.
Use a singular example to highlight the absurdity that has become the new normal. Dave used one picture of the Scaled Agile Framework:
Contrast this with the four values and twelve principles of the Manifesto for Agile Software Development
We are uncovering better ways of developing software by doing it and helping others do it.
Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
Principles behind the Agile Manifesto
We follow these principles:
- Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
- Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
- Deliver working software frequently, from a couple of weeks to a couple of months, with a preference for the shorter timescale.
- Business people and developers must work together daily throughout the project.
- Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
- The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
- Working software is the primary measure of progress.
- Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
- Continuous attention to technical excellence and good design enhances agility.
- Simplicity–the art of maximizing the amount of work not done–is essential.
- The best architectures, requirements, and designs emerge from self-organizing teams.
- At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
Explaining the Manifesto for Agile Software Development can be done in a few hours. Explaining SAFe can take weeks.
The last step in the story is a return to the original values of an idea and potentially introduce a shiny new toy. Dave proposes a simple four-step process that can be universally applied:
- Find out where you are
- Take a small step in the direction towards your goal
- Adjust your understanding based on what you have learned
Dave’s recommendations are even simpler than the original Manifesto for Agile Software Development. He didn’t propose a shiny new toy.
Some people go a step further and describe a shiny new toy you should chase. For example:
- Ditch COBOL and get RPG. Ditch RPG and get Basic. Ditch Basic and Get C, . . .
- Ditch Structured Analysis and Design and get Information Engineering. Ditch Information Engineering and get UML. Ditch UML and get Agile
- Ditch Agile and get SAFe. Ditch SAFe and get Lean Enterprise. . .
There is a tendency to declare something dead so you can move on and sell a shiny new toy. In reality, there are aspects of many once-popular system development methods and technologies that survive today.
- The online fax market will be $1.31 billion in 2021. Artizon Research
- There are over 220 billion lines of COBOL in existence, a figure which equates to around 80% of the world’s actively used code. Codinghorror
- Rapid Application Development (RAD) and Computer Aided Software Engineering (CASE) tools were declared dead in 1999. Low-code platforms are their successors. The worldwide low-code development technologies market is projected to total $13.8 billion in 2021, an increase of 22.6% from 2020, Gartner.
- Mark IV, the first fourth-generation language introduced in 1968 has recently been updated to support IBM z/OS 2.4
Scott Middleton correctly points out in Agile is Dead, McKinsey Just Killed It that Agile has entered Gartner’s Plateau of Productivity:
While the pundits may be declaring Agile dead after 20 years, its use and influence will continue.
While the creators of new methods and techniques proclaim their solution to be the best, history has shown that there are no magic bullets.
Especially in the technology market, there is a tendency to follow new prophets. The early days of system development were led by outsized personalities like Barry Boehm, Edgar Codd, Tom DeMarco, Ed Yourdon, James Martin, and Grady Booch, They wrote books, consulted, and gave seminars to thousands of acolytes. In contemporary times new prophets have emerged like Mark Zuckerberg, Tim Cook, Eric Reis, Jeff Bezos, and even Elon Musk.
There are many aspects of these prophets’ approaches that are worth leveraging., some are worth ignoring. Even Edgar Codd, who first postulated the rules of relational database normalization, had some whacky ideas. When IBM failed to embrace his revolutionary thinking about relational databases Codd coined the term Online analytical processing (OLAP) and wrote the “twelve laws of online analytical processing”. Controversy erupted, however, after it was discovered that this paper had been sponsored by Arbor Software (subsequently Hyperion, now acquired by Oracle), a conflict of interest that had not been disclosed, and Computerworld withdrew the paper.
As Dave Thomas pointed out in his presentation (starts at minute 31:00), no rules are universal, rules need context. Paraphrasing Dave, e said it is generally a rule that you should not stab people in the neck with a knife. Unless you are a doctor performing a thoracotomy to save someone’s life. All experts that tell you what to do and how to do it are wrong. Any book that tells you how to write software is wrong. Unless it was written for your team, your company, your project, at that point in time, they’re wrong.
The key takeaway from the Agile is Dead story is that you should experiment to see what works in your environment. Every company is in a unique place at any point in time. Your market position, your level of resources, your ability to execute are all specific to your situation. As Dave Thomas says no rules are universal. What works for Google may not work for you.
You should not abandon things that have worked in the past in favor of some shiny new toy just because they’re old. Edgar Codd’s approach to database normalization works just as well in 2021 as it did in 1972. UML state machine diagrams are still an efficient way of documenting complex designs. Spring planning, daily standups, and retrospectives are still very effective ways to build software. You should synthesize what has worked in your environment with new ideas.
As Heraclitus said in 500 B.C. “the only constant in life is change”. When it comes to software development change is constant. New technologies, new methods, and new business models emerge almost every day. You should leverage these advancements while keeping the best of what has worked in the past.
Also published on Medium.