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.
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.
I'm not sure the 'there's no such thing as bad publicity' works when you're aiming to come across as a voice of reason in the software community.
I think the discussion could have been nipped in the bud if it was described similarly to your summation - a necessary business decision rather than good software practice.
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...
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.
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.
[1] http://www.joelonsoftware.com/articles/fog0000000069.html