The Eternal Optimism of the Spotless Repository

We’re programmers. Programmers are, in their hearts, architects, and the first thing they want to do when they get to a site is to bulldoze the place flat and build something grand…It’s important to remember that when you start from scratch there is absolutely no reason to believe that you are going to do a better job than you did the first time.

Joel Spolsky in Things You Should Never Do, Part 1

There is a fleeting moment in every software project when it is absolutely perfect. It is the time between clicking “New” and “Save” in your code editor. In that brief interval, limitless potential and beauty. In every moment that follows, compromise and doubt (but working software, too!). Thus rule #24:

The original sin of code is writing it.


No wonder the siren song of rewriting from scratch is so hard to resist. It’s a chance at redemption. But what about an entire programming language? The creator of JSON thinks it’s a dandy idea:

The best thing we can do today to JavaScript is to retire it. Twenty years ago, I was one of the few advocates for JavaScript. Its cobbling together of nested functions and dynamic objects was brilliant. I spent a decade trying to correct its flaws…But since then, there has been strong interest in further bloating the language instead of making it better. So JavaScript, like the other dinosaur languages, has become a barrier to progress. We should be focused on the next language…

Douglas Crockford

Replace JavaScript with the name of whatever you’re working on, and this conversation happens everywhere software is being made all the time. The causal disdain for “dinosaur languages” is a nice touch. Joel has something to say about that too:

Before Borland’s new spreadsheet for Windows shipped, Philippe Kahn, the colorful founder of Borland, was quoted a lot in the press bragging about how Quattro Pro would be much better than Microsoft Excel, because it was written from scratch. All new source code! As if source code rusted.

We all know how that worked out for Borland.

Of course, JavaScript is terrible. Is it scalable? No. Is it maintainable? No. Is it portable? Not really. But to paraphrase Winston Churchill, JavaScript is the worst web programming language, except for all the others that have been tried. As bad as it is, it’s pitfalls and shortcomings are thoroughly documented and understood. It is ubiquitous. As a working software developer, you’re almost certainly better off spending your time getting better at the language you’re using than jumping to a trendy new one. With JavaScript you may not enjoy the journey, but you will reach your destination. If you have the time and money to chase utopia, by all means please create the perfect language. If you have to ship a product to put food on your table, choose the devil you know over the one you don’t every time. And thus rule #17:

Legacy == proven

Also me

Things you should never do, even if you are a $FAMOUS_COMPANY using $HYPED_TECHNOLOGY

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.

“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

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.