Could have just shipped the customer a server, especially as Joel's article suggests that most of your on-prem customers went with dedicated servers for the software anyway.
Find it hard to imagine that a significant percentage of your customers were 100% linux/mac to the extent that they'd refuse any win boxes in their shop.
I was in IT at the time and catered to a number of 100% mac shops (mostly ad agencies/gfx design studios) and there were always one or two win boxes around, usually a couple for fileserver/backup and one for the sysadmin to do sysadmin things with.
>We couldn’t go back in time and decide to write it in a different language.
You had an intern write a program that rewrote it in a different language for you, time after time after time.
We didn’t have the margins to ship physical servers to customers. User seat licenses were $100 or so, and most customers were SMBs - 5-15 users, so we would have lost money on shipping any customer a Dell with Windows Server on it. We didn’t have a sales channel for real enterprise customers until quite late in the lifecycle of the product, so even our biggest customers weren’t that big.
Joel said PHP and Python were non-starters on Windows. We could have used the compiler to do a one-time cutover to C# in 2008, but the CodeDom generated code was fairly icky, so we decided to keep the Wasabi code and just ship the machine-generated DLLs with friendly Wasabi debugging symbols. We were only able to cut over once I rewrote the generator (I think that was the fifth generator, and there was also a Wasabi interpreter for compile-time evaluation… PHP, JS, ASP, .NET DLL via CodeDom, plain C#) using Roslyn. That took me just over a month, in two phases: first, use Roslyn to generate duplicate code to the CodeDom backend (2-3 weeks). Then, I deleted the CodeDom backend and started making syntactic improvements (and generate comments and white space!) until I hit the point of diminishing returns (1-2 weeks). Finally we checked in the C# source code, removed the Wasabi build step, and let ReSharper go to town. (2 days)
Each step we took was low-risk, because it didn’t create any new technical debt or accumulate as inventory. Each step was small and low-cost. None of them were the optimal step, but they also didn’t risk the entire business on stopping-the-world.
There were plenty of other disasters in that codebase. For me, the FogBugz Plug-in Architecture was the worst of all of them. Adding all those layers of indirection, plugin hooks was a huge performance cost, and maintenance burden because we couldn’t ever change function signatures once they were shipped. I wish we had just added web hooks. That would have gotten us 95% of the extensibility with 10% of the performance cost, and 0% hosting other peoples’ code in our FogBugz On Demand web server processes. I think I once murdered a fledgling startup by mentioning we were thinking of removing it.
Thanks for the context, I appreciate it. At the time I remember the concept of running PHP on Windows/IIS did have this air of 'hmmmmmmmmmmmno' associated with it.
In my experience it ran fine, but for obvious reasons when shipping software that might make or break their company I can understand Joel preferring the familiar territories of ASP/IIS/Win or LAMP.
