I can't go into the full background and a couple of details have been changed to protect the innocent, but I was chatting with a company that I'll call Acme. They faced a situation that I've seen before and usually ends badly. The code base they have looks like this:

Roughly a million lines of legacy spaghetti code

Very little use of existing libraries ("not invented here" syndrome)

Siloed developers

Hard to maintain and extend

Prospective developers see the code and "nope" the heck out of there

I have spoken to quite a few companies in this mess and Acme had a solution for dealing with it: they were going to rewrite the code base in another language.

Oh really?

A million lines of code, in heavy use, is going to be rewritten? Let's do some rough math.

We know that lines of code is a rubbish metric for productivity, but in this case, it's really all I have to work with. I pulled out an old project of mine and saw that I did six months of development on it. How do I calculate the lines of code I've written? Well, I can't, not really, but for the sake of argument, let's make a quick guess. Given a starting and ending commit, here's how I can calculate how many lines of code I've changed over the course of the project (using git):

git log --numstat --pretty="%H" --author=ovid $first_commit..$last_commit \ | perl -anE 'if (3 == @F){ $a+=$F[0];$b+=$F[1] } END { say "+$a -$b" }'

And that printed my total insertions and deletions: +76294, -32686. That makes for just over 100,000 lines of code changed in six months, but even then, it's a rubbish, rubbish metric. No matter how I play with the numbers, I get between 300 to 1,000 lines of code a day. I'm productive, but that number seems very high. On the other hand, the project lead commented that I was productive enough that it was hard to do code reviews, so maybe that's not too far off.

Let's forget about the 10 lines of code a day that we sometimes hear and pick 500 lines of code a day. That's being generous. Very generous. Further, let's assume that we can maintain this pace and that the old code base will be written in a language with similar verbosity. That's roughly 5.5 person years of effort to rewrite to rewrite the code base, but that assumes you're working seven days a week, 365 days a year. In reality US workers typically work roughly 2,000 hours per year, or about 250 days out of the year. That means it would take eight person years of effort to replicate the above code base (over ten years for the average hourly hours here in France).

And that's assuming you could consistently crank out 500 lines of code a day. So we'll forget about the lessons of the Mythical Man Month and assume 8 developers could crank this out in a year. Assuming that each developer annually costs the company around €100,000 (that's salary, insurance, taxes, training, supporting equipment, etc.), and assuming at least two other employees will be there to coordinate the project, that's a €1,000,000 they're going to spend.

No, that's not true. That's a one million euro they're going to flush down the toilet and reach for the euro roll again. Acme's developers have meetings. They have "off days". They have to spend time understanding the original code base: they can't just transcribe it. Work will still have to continue on the old code base. Features added to the old would have to be added to the new. Features taken for granted in one code base won't be available in the other. Modules working in one code base won't be available in the other (or worse, may be available but you'll miss all the interface differences). And then there's the work coordination necessary between eight devs. Further, because of the lack of structure in Acme's old code base, simply transcribing it would turn one steaming pile of ones and zeros into another steaming pile of ones and zeros. I suspect new team would be lucky to get 500 lines of code a day for the entire team. Very lucky. This project, even if wildly successful, is going to cost many millions of euros.

And now Acme has to have the new development team and the old development team sticking around, greatly increasing their costs (or retrain the existing devs). At the BBC, as soon as they announced they were switching from Perl several Perl devs announced they were quitting and taking their hard-earned business knowledge with them. Why stick with a company when you know you don't have a future? (Actually, your future is likely guaranteed, but grudgingly.) And I might add that Perl is still heavily used at the BBC, several years later because "see above". (And guess why COBOL is still so heavily used? See above.)

Note that the above isn't an analysis. It's a "pie in the sky" best case pipe dream that simply won't happen. You can pull this off for smaller code bases, but even then it's painful, expensive, and time-consuming. The industry is riddled with projects (and companies) that have failed because of rewrites (anyone remember Netscape?).

I have been at multiple companies that have decided to change programming languages, but they're generally not foolish enough to blindly rewrite their systems[1]. I worked with two companies that switched to Ruby on Rails and subsequently ditched it (both for Perl), only to find that they don't have the time to replace it. So now they have legacy Rails apps that they have to maintain because they don't have the time or money to simply rewrite them. And these were small compared to a million line code base.

So Acme has decided to spend millions of euros to switch from their current high risk/low reward position to a new higher risk/low reward position. I fail to see the cunningness here. Unfortunately, I understand what happened. At another company, the CEO panicked in a financial crisis and fired the dev team that had been working for one and a half years to develop a complicated project in part because an outsourcing company in India promised they could replicate it in two months — for a lot less money. Non-technical people often have no understanding of how hard our work is.

Acme's solution to their current woes clearly fits the definition of "large project" and we know from decades of painful experience that large projects fail. They're so disastrous that almost one fifth of large software projects threaten the very existence of the company. Would you dare go to the Board of Directors and say "I have a multi-million euro software project that if it succeeds, will make it easier to hire developers, but it will probably fail and has almost a 1 in 5 chance of bankrupting us?" No, you wouldn't, but Acme did.