I like to joke that 90% of my job is just telling developers “No you can’t rewrite that.” Joel Spolsky explains why, and why why you’re not reading this in a Netscape browser, in his seminal article Things You Should Never Do, Part I

When you throw away code and start from scratch, you are throwing away all that knowledge. All those collected bug fixes. Years of programming work.

You are throwing away your market leadership. You are giving a gift of two or three years to your competitors, and believe me, that is a long time in software years.

You are putting yourself in an extremely dangerous position where you will be shipping an old version of the code for several years, completely unable to make any strategic changes or react to new features that the market demands, because you don’t have shippable code. You might as well just close for business for the duration.

You are wasting an outlandish amount of money writing code that already exists.

Which is why this parody template of a press release had me in stitches – Why we at $FAMOUS_COMPANY Switched to $HYPED_TECHNOLOGY

When $FAMOUS_COMPANY launched in 2010, it ran on a single server in $TECHBRO_FOUNDER’s garage…Our existing technology stack has served us well for all these years, but as we seek to grow further it’s clear that a complete rewrite of our application is something which will somehow prevent us from losing two billion dollars a year on customer acquisition.

…the $FAMOUS_COMPANY backend has historically been developed in $UNREMARKABLE_LANGUAGE and architected on top of $PRACTICAL_OPEN_SOURCE_FRAMEWORK. To suit our unique needs, we designed and open-sourced $AN_ENGINEER_TOOK_A_MYTHOLOGY_CLASS, a highly-available, just-in-time compiler for $UNREMARKABLE_LANGUAGE.

Read the whole thing, as they say.

Legacy == Proven. It’s as true today as it was when Netscape was on top and threw it all away.

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

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