Wow, something clicked while I was reading that. Wasabi is the result of following "Things You Should Never Do [1]" as a motto. Not that it's a bad thing (it's not), but it just explains so much.

[1] http://www.joelonsoftware.com/articles/fog0000000069.html

Yes, I noticed that this story was a parable of what happens when a charismatic leader declares something taboo, because of all the unforeseen problems it always causes, so the acolytes resort to a workaround that has the same problems in a different form but does not violate the religious taboo.

There is inevitably a Law of Conservation of Coding Cost that will get you one way or another. If you won't rewrite your code from scratch (because of all the unrecognized wisdom in the old code), you'll build a compiler from scratch (and discover all the unrecognized wisdom in proven compilers), or you'll switch to some proven cross-platform solution that will cover most of your needs, but the remaining pieces needed to complete the job, when added together, will introduce you to all the unrecognized wisdom embodied in the standard, platform-specific toolchains, or some other approach that will preserve the cost in some other way.

This "never rewrite from scratch" dogma is an example of incomplete wisdom.

I disagree. Joel's "Don't rewrite from scratch" mantra seems like pretty solid risk-avoidance, given his first-hand experience with that path.

The cost to build and maintain Wasabi was surely higher than rewriting as X, but the risk sounds substantially less, and effectively spreads the risk part of technical debt over future years.

Thistle came out TEN YEARS ago, and Wasabi isn't much younger. Choosing the path they did arguably contributed to them being able to survive this whole time - and, having read Joel's creed on rewrites, I'm not sure they'd have done better if they rewrote as Python or Javascript.

That was my take on it.

A bad rewrite could have killed the company. Historically, rewrites do not have a good delivery record.

A sideways sort-of-DIY ever-expanding transpiler-or-whatever kept the project alive and profitable.

Sometimes an ugly hack is the right answer if it keeps the money coming in.

Also, valuable PR.

Problem with rewrites is there is the terrible gap that opens up between the old stuff which goes stale quickly, and the new stuff which isn't ready for prime time. Cash-flow then dries up right as the amount of work needed is maximal. Death follows quickly.

Here they did not rewrite from scratch they developed a bridge that allowed them to keep moving forward as the world that the old software was based on disappeared. And now they are on the other side with a code-base that works and has been providing cash-flow the whole time.

I think it's related to the Waterbed Theory[1]. Or, put another way, there's no free lunch. The bill will be paid, either now or later, by you or someone else. You're probably better shifting responsibility than time...

1: https://en.wikipedia.org/wiki/Waterbed_theory

At what point was FogBugz rewritten?

Wasabi is a compiler. The output of Wasabi was C# code. One day, I deleted Wasabi and checked in the C# code. I did not have to rewrite FogBugz in the slightest.

Ohhh, I thought the target was CLR. I didn't realize it was a transpiler.

Ohhh, I thought the target was CLR. I didn't realize it was a compiler.

FTFY

transpiler ⊂ compiler

(lightbulb!)

but, and maybe they were also recompiled, did you keep your tests as well?

Most of them are NUnit tests, which don't care what source language the assembly under test is written in.

A few of the oldest FogBugz tests are in `unitTest.asp` and were written in Wasabi. They got transpiled over to C# like everything else. Some are confirming Wasabi language features (e.g. `testLambda`, `testDictionary`, `testErrorHandling`), so I could remove them.

All of Wasabi's unit tests were deleted with Wasabi.

In my (brief, haphazard) research for this article, I somehow missed this article. Thanks for sharing it. I really like the analogy with a bridge loan.

Given both the tedunangst's article and yours, I wonder what has happened to the JavaScript output feature? I don't seem to see it mentioned in your article? But I don't really know about Roslyn, so I'm not sure what it provides; does it have anything helpful? (I assume it has some kind of a C# generator; probably a C# parser too?), but - either you don't have a need for JS output anymore, or you've written a C#->JS translator? (Or used some 3rd-party one?)

I'm very curious, would be grateful for an answer! tx

See https://news.ycombinator.com/item?id=9780798 - I took the output of Wasabi's JavaScript generator and checked it in to source control. If someone wants to change the JavaScript, they have to do it manually, as there is no longer any program maintaining that code for them.

Roslyn is an open-source implementation of the entire C# compiler, with some fantastic design decisions that allow you to use it in pieces or all together. https://github.com/dotnet/roslyn I used the C# generator portion of the platform.

At least you found the wiki page for soy sauce. :)

Actual, informational, thoughtful post from someone who has first-hand knowledge of an act of actual software engineering.

Thanks for posting.

So what happened to the JavaScript code that was compiled from Wasabi?

I would be fascinated to know as well. Either incrementally replaced before hand, or one shot translated?

It got checked in as-is. FogBugz Ocelot doesn't use it, so there's rarely any reason to modify it.

Oh. Ocelot was obviously a bigger technical change than I thought. You should write that up too. :)

I personally did not have anything to do with Ocelot, so I'll have to leave that to someone more qualified :)