Joel is Wrong, and it costs you a fortune
By: Daniel Schwartzer
Tags: Refactoring, Architecture, Joel Spolsky, Serverless, Software Development

If you’ve been around the Software industry for a while, you must know who Joel Spolsky is. In his blog Joel On Software, his monumental The Guerrilla Guide to Interviewing, Things You Should Never Do, Part I and other posts have faithfully served managers for years, and have become the de-facto standards on these topics. You should definitely read at least these two, if you haven’t done so already.

Most managers I worked with, have not only read these posts, but also are were very much driven by them, including me — they’ve helped shape much of my managerial paradigms for years.

It’s only that “Things You Should Never Do”, in which Joel explains why you should never rewrite software from scratch, is no longer correct. That may have been true 20 years ago, but in 2020 it’s an outdated way of thinking.

Now in all fairness, I haven’t caught up with Joel personally to discuss whether he’s changed his thinking, but a reference to his post came up during internal discussions recently. So I thought it important to offer a counterpoint and explain why relying on that post can cost companies a fortune today. Let me explain.

The Age of Transformation

These days, it seems, every software company is undergoing the same process of Transformation. It may take several names “Digital transformation”, “Breaking the Monolith”, “Micro-services”, “Cloudification/SaaS-ification” and “Going Containers/Serverless” — but regardless of what you call it, these projects generally come with a heated debate over a very pivotal question: Evolve or Rewrite. Often management vouches for Evolution, while architects pledge for a Rewrite. Until recently, along with many other managers, I heard echoes of Joel’s post in my head: “Remember Netscape?” and almost always voted for Evolution.

Even today, I hear managers referring to Joel’s post and mourning Netscape when the decisions are being made. As we’re approaching the 20th anniversary of that post, let’s give it another going-over, and let it go for good. You can’t revive Netscape 4, but much has changed since 2000, and it’s time you adjust too. After all, it is the age of Transformation.

Foul Reasons to write from scratch

Joel introduces the following reasons behind programmers’ desire to rewrite from scratch:

“First, there are architectural problems. The code is not factored correctly. The networking code is popping up its own dialog boxes from the middle of nowhere; this should have been handled in the UI code… A second reason programmers think that their code is a mess is that it is inefficient… Third, the code may be doggone ugly.”

If these are indeed your reasons to demand a rewrite, I’m a 100% with Joel — they can be fixed or refactored by any of the Evolutionary methods.

Programmer’s case revised

Let me make the case for the collective persona of the programmer entering 2020.

In the age of Cloud Computing and Open Source Software, and especially with the rise of Serverless Technology, when we look at our legacy code, we find that most of it is simply irrelevant. The problems it tackles and the solutions — all of it. It doesn’t need to be rewritten, it needs to go.

Modern technology provides a whole new level of abstraction and an unprecedented speed of development. You can literally produce an infinitely scalable production code in a matter of hours, if not minutes. There’s no more bare metal provisioning, OS, VMs, OS-specific languages, compilers — at least they’re not visible to you. Even Web Containers are being replaced by API GWs and Functions. We need to concentrate on our business and bringing value to customers. Customers’ expectations of software have also evolved, and we can’t satisfy them with tools and methods from the last century.

When we hold our development teams back, we not only restrain them from gaining proficiency with modern tools, but we are also unable to keep pace with a potential competitor, who doesn’t carry the burden of past success. We can’t win.

I guess all I’m saying is this. The software industry has undergone a major leap in the tooling, architectural paradigms and computing abstraction. Customers’ requirements have also changed since the original code was developed. Just as you can’t win a modern war with a sword, you can’t compete in the modern world with tools from the past.

Joel is talking about rewriting the same software for the same customers with the same requirements, and most importantly — using the same-generation tools. And that is exactly where they fall short.

Joel brings a list of failed “rewrite from scratch” projects. I could just as easily make an opposing case of companies who moved slowly, failed to innovate, and were overtaken by quicker competitors. Or, on the contrary, a horde of evolutionary projects which got stuck in the mud midway, producing a half-finished architecture and only increased the complexity of the solution and slowed the development even further.

Dangerous Assumptions

Let’s switch gears and review some of the Joel’s assumptions and then look at them from the 2020 perspective:

Assumption 1: Programmers think the old code is a mess

“[Programmers] think the old code is a mess. …they are probably wrong. The reason that they think the old code is a mess is because of a cardinal, fundamental law of programming: It’s harder to read code than to write it.”

Assumption 2: Newly written code is no better than the old one

“… 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… The idea that new code is better than old is patently absurd.”

Assumption 3: By rewriting, you throw away all the years of accumulated knowledge

“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.”

Assumption 4: You may lose your market leadership if you take a long time to rewrite

“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.”

Assumption 5: You’re going to repeat all the previous mistakes

“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. First of all, you probably don’t even have the same programming team that worked on version one, so you don’t actually have “more experience”. You’re just going to make most of the old mistakes again, and introduce some new problems that weren’t in the original version.”

Here is my modern take these assumptions with a view of today’s technology.

All code gets messy as time progresses. All code deserves refactoring and tending. Code doesn’t “rust” (as Joel refers to it), but it rots with time (switches hands, ugly patches are added, etc.). In either case, you will need to tend to it. This is not a reason to rewrite.

Yet in many cases, say for code older than 10 years, it likely solves a problem someone else has solved already, and probably better than you did. It’s likely available as one of the Cloud services, or an open source library. Leaving this irrelevant relic of history inside your code is a form of tech debt — and it costs you, even if it lays dormant.

There are exceptions, of course, but these days you normally don’t develop your proprietary TCP-level protocols, user registration and authentication modules, or email sending components.

New code is better because it’s developed with tools addressing modern problems. It’s 100 times more concise and simple, and probably requires much less experience to develop and maintain.

You bring new knowledge on-board — knowledge on modern ways to do things, as well as modern libraries, tools and solutions. Your proprietary business logic is probably only a small fraction of your code. Yet, if you have someone on-board who remembers the intricacies of business-related logic, it can be valuable.

Diving head first into the “rewrite from scratch” project is risky. Especially if you stop maintaining your current offering and focus all your headcount on the new project.

Yet in order to maintain market leadership, you must stay up-to-date with new technology — your teams must be proficient in them. Dragging your feet with gradual changes may not only cost you the market leadership, it will cost you the expertise of your team. A recommended alternative is a domain driven approach, where at each phase you only rewrite a subset of your whole system.

As with all other assumptions, if you’re planning to use the technology and tools from the same “generation”, Joel may be right. But, if you’re using tools from the higher abstraction layers, it’s a whole different game.

At the dawn of the human era, one of the rules of the game was “never put down a fire — starting a new one is costly and life-threatening”. Things have changed, and it’s time to reexamine the assumptions.

After almost 50 years, even Moore’s law is reaching its end of life. Joel’s “never rewrite” has held strong for 20 years, and it’s time to plan for its retirement.

Don’t be reckless or naive, but blindly following “never rewrite” in 2020 will cost you a fortune, endanger your market leadership and make you irrelevant.