Hacker News Reader

Isn't the story of Wasabi that changing OS's and dev platforms is manifestly not a good reason for a rewrite?

People seem to be mistaking the big story about Wasabi today. Wasabi worked. Yes, they're migrating away from it --- ten years after introducing it. They defered to 2015 what people on HN are telling them they should have done in 2005.

Not only that, but the "port" to C# was mechanical. They didn't rewrite to get away from Wasabi. Because they put the time in to build Wasabi, all their code was instrumented, and they were able to write a program to do the final port. They deferred the port for a decade, and also mechanized it.

I can't help but think you've taken exactly the opposite message away from the posts today that the authors intended.

There's nothing new here, a company can have a crap tech stack and still build a successful product if it has a competent team and good leadership.

This was I imagine a bit of a PR problem for FogCreek, because at the end of the day they were using Visual Basic to build a Windows-only website, not exactly the most awesome stack in today's world (or yesterday's for that matter).

It's normal that they want to communicate to the world the fact that you won't have to learn their custom version of Visual Basic in order to work there. It's also normal that people aren't giving them a pass that easily.

I think you may have commented on the wrong thread. I can't see what your comment has to do with mine.

    > I don't think I know anybody personally, whose response
    > would be, "I know, let's write a compiler to translate
    > our VBScript into something that runs on Unix."

That's not how these things happen in the real world, though.

They happen when somebody says "You know, VBScript looks a lot like PHP. I wonder how much of our code would run with some simple regexes transforms" and gets 40% of the codebase "compiling" with some helper functions. And then someone realizes that regexes don't quite cut it, and actually look here's this VBScript grammar I found online, and it's only two days work to convert the AST to PHP, and 80% of the codebase compiles... And a little while later, you realize that you have a commercially viable alternative to a Big Bang Rewrite.

> can anyone tell me coherently why Joel didn't push for a rewrite when he received the requirement to support Unix servers?

I probably can: "How much money are we really going to make from Unix servers?"

He almost certainly had people complaining about lack of Unix support. But the question was: "If we expend all this energy supporting Unix, will they pay us enough for it to be worthwhile?"

I suspect that the answer was: "Not really, but we can't bid on enterprise without that support"

So, they had to keep a single, unified codebase to keep the cost to support Unix down while only adding some controlled cost support increase to Windows.

The thing is, for real "enterprise" customers who wanted unix you would just bundle Chilisoft ASP into the quote. They would also probably want to use Oracle for the RDBMS which would dwarf the cost of Chillisoft.

But you still have to do the development and debugging.

I've used lots of closed-source "substitute, but just as good for porting" packages over the years. They NEVER work--sure they get the easy 70%, but they all miss the 30% of edge cases that code somehow always manages to trigger. I am not interested in debugging your porting library so you can make more money, thanks--especially if it is likely to piss off a customer. I will control my customer experience as that is my money.

The only exception to this is if you release your code open-source. Then I might adopt it since I can fix a showstopping bug myself if I need to for a customer.

Here's my litmus test if your closed-source package on Unix might be acceptable: Do you support FreeBSD? My team is smart enough to abstract code in such a way that it can run on Linux/FreeBSD/Solaris without killing ourselves. If your team can't do that, it's just going to get in our way.

Hm, your tone is a bit puzzling. Chilisoft ASP was mentioned in the original article as a "Boom. Done." solution. By all accounts I've seen, it was a complete implementation of ASP. ASP was tiny. There were six objects: Request, Response, Server, Application, Session, and Error. Not a lot of room for undetected edge cases, and if there are, likely not harder to work around than the ones in your own porting library.

Anyway the point is, if you are selling to "enterprise" especially at that time, open-source is a scary, uncertain proposition. Enterprise buyers want vendors with phone numbers and help desks and support agreements and maintenance plans. Your sales guy just says, "Sure, unix, fine, no problem" and bundles Chilisoft into the quote.

Ayup. "Boom. Done." It just exploded, and your company is now done.

There is no such thing as "Boom. Done." when I have to answer the call when it goes "Boom." Enterprise customers won't allow me to say "Call Chilisoft"--they will yell at ME to fix things. If I can't fix it, I lose the customer.

If it was so easy and small, why doesn't there seem to be an open source version of it? If it was so easy and small, why did Chilisoft sell for almost $100 million?

Open-source wasn't scary at all to enterprise vendors as they didn't even know it was there if the software used a BSD-like license. Only the GPL causes enterprise legal panic like syphilis in a whorehouse.

> Request, Response, Server, Application, Session, and Error. Not a lot of room for undetected edge cases

Famous last words, son. Like everything, seems simple enough up front, but since it's closed source, you have _no idea_ what's going on in there.

I don't think I know anybody personally, whose response would be, "I know, let's write a compiler to translate our VBScript into something that runs on Unix."

Yeah it was an odd strategy, I agree. But on the other hand, translating one scripting language to another doesn't sound sound that unreasonable either.

From the article:

The super obvious answer is to tell unix customers to install Chilisoft ASP. Boom. Done. Except it costs more than FogBugz does.

I remember hearing of Chilisoft ASP. Never used it, and I have no idea what it cost. I'd be curious if they attempted to negotiate any kind of discount for Chilisoft ASP, maybe locked to FogBugz somehow. Compared to running FogBugz on ASP, which I'm guessing would have required at minimum a Windows Server and a SQL Server license, you'd think some kind of deal could have been arranged.

The other thing I'm curious about is how many Unix installations of FogBugz were sold? From what I've seen, customers who are willing to actually pay for a bug tracker would not blink about buying a Windows server to run it, if that's what it required.

Having listened to nearly all of Spolsky's SO/SE podcasts, I think the other factor is that Spolsky's strategy has been to control critical dependencies by keeping them in house. StackExchange runs on its own servers rather than in the cloud so that problems fall into StackExchange's queue not in with other people's at a cloud computing provider. If FogCreek had made Fogbugz depend on ChilliSoft, then infrastructure problems with Unix integration would have been fixed on ChilliSoft's timeline if they were fixed at all. Writing Wasabi meant that Fogbugz had a more predictable development schedule controlled and instrumented by FogCreek.

It seems to me, as an outsider, that Joel's reason for avoiding a rewrite at any cost is because so many rewrites have failed. Perhaps it's better to prefer steady, step-by-step progress over a giant leap that might be a leap backward in the end. What is often forgotten in these discussions is that, because Fog Creek had talented programmers, writing Thistle and eventually Wasabi was just another series of steps on the road, not a giant leap as a rewrite would be.

Well, the task of writing the compiler was given to an intern, so I would guess it was an experiment that ended up working well enough that became their strategy for supporting Unix.