“Why are people so excited to announce the death of software development paradigms?”

Thus begins John Mecke’s essay Agile is Dead (So is COBOL, XP, RAD, UML, SAFe, etc). It’s an enjoyable, step by step takedown of the {whatever} Is Dead new paradigm promotion treadmill.

The key takeaway … 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.

Legacy == Proven

And the Rule 17 Lifetime Achievement Award goes to…COBOL

The sheer age of those COBOL systems is, oddly, actually something that works in their favor. Because they’re old, they have been relentlessly debugged. When a program is first written, it inevitably has problems…But those COBOL programs that run the world? They’ve had decades for coders and users to uncover all the problems, and to fix them…They’ve been debugged more than just about any code on the planet. This idea — that older code can not only be good, but in crucial ways superior to newer code — is at odds with a lot of Silicon Valley myth making.

Legacy == Proven.

Clive Thompson on the enduring fitness and necessity of COBOL https://www.wealthsimple.com/en-ca/magazine/cobol-controls-your-money

Cleverness is the Mother of Regret

Scott Locklin on the wisdom of rules 6 and 17

One of the valuable things about popular but boring languages is that the code has been traversed many times, and routine stuff you’re likely to use in production is probably well debugged… The other benefit to boring languages is people concentrate on the problem, rather than the interesting complexities of the language itself.