Here's a list of interesting concepts in software development. Now think about it: who do you think might have stated them so clearly?

• Design for Iteration:

  "...as each step progresses and the design is further detailed, there is an iteration with the preceding and succeeding steps..."

• Get Feedback:

  "If the computer program in question is being developed for the first time, arrange matters so that the version finally delivered to the customer for operational deployment is actually the second version."

• Sharing Knowledge:

  "Each and every worker must have an elemental understanding of the system..."

• Centrality of People:

  "...the personnel involved... They must have an intuitive feel for analysis, coding, and program design. They must quickly sense the trouble spots in the design, model them, model their alternatives, forget the straightforward aspects of the design which aren't worth studying at this early point."

• Code Review:

  "...every bit of an analysis and every bit of code should be subjected to a simple visual scan by a second party."

• Automatic Tests:

  "...every logic path in the computer program at least once with some kind of numerical check."

• Involve Customers:

  "...it is important to involve the customer in a formal way so that he has committed himself at earlier points before final delivery. To give the contractor free rein between requirement definition and operation is inviting trouble."

Who said that?

I'm afraid these words are not the result of your favorite Agile programming guru. Quite the opposite.

These are all sentences taken from the 1970 paper considered to be the manifesto of the Waterfall design paradigm. That's right—the supposedly rigid and inflexible methodology. The paper is called Production of Large Computer Programs by Herbert Benington.

The False Dichotomy

How is that possible? Agile, Scrum, Waterfall—it's like a war among 'philosophical' schools, each one promoting a different solution to the dilemma of how to achieve the most efficient software development process. In reality, there is often a significant difference between what was originally proposed and what people make of it over the years.

That's the main thesis of an inspiring keynote talk by Paolo Perrotta (in Italian, I'm afraid). Essentially, what he suggests is that Waterfall wasn't that evil after all. But Waterfall achieved success, and as a consequence, it sold out. Or rather, it was emptied of its original ideas and principles, then modified and misinterpreted to cover a multitude of usage scenarios and personal preferences.

The Agile Paradox

Perrotta warns us that we should recognize that the same is happening with Agile. Its massive success is leading to the transformation of its principles into empty buzzwords, and its core functions into roles that are often performed by people according to predefined scripts with little understanding of the methodology's core ideas. At the end of the day, both approaches presuppose one central tenet: being reasonable.

The lesson here is clear: methodologies are tools, not religions. What matters most is not which methodology you choose, but how thoughtfully you apply its principles. When we treat Agile as a checklist of practices rather than a mindset, we risk repeating the same mistakes that turned Waterfall into a bureaucratic nightmare.

Conclusion

Thanks to Paolo for these thought-provoking ideas (and thanks to Enrico for bringing this to my attention)!