Hacker News Reader

Comment by Alupis | Hacker News Reader

It is usually a "colossal error" to write your own in-house closed-source/proprietary language, no matter how small or large the language is.

The main reason is exactly as the article states, maintainability.

> As time wore on, our technical debt finally began to come due. Compilers like Wasabi and their associated runtime libraries are highly complex pieces of software. We hadn’t open-sourced it, so this meant any investment had to be done by us at the expense of our main revenue-generating products. While we were busy working on exciting new things, Wasabi stagnated. It was a huge dependency that required a full-time developer — not cheap for a company of our size. It occasionally barfed on a piece of code that was completely reasonable to humans. It was slow to compile. Visual Studio wasn’t able to easily edit or attach a debugger to FogBugz. Just documenting it was a chore

View on HN

What am I missing? This is an internal language designed as an incremental improvement over VB that gave them cross-platform common codebase. It lasted 10 years: that's 19,932 in SaaS years. When they transitioned off of it, they did it not with a rewrite, but with mechanical translation.

It seems like a spectacular success story.

Perhaps even a case study of technical debt done right?

I mean, adding an esoteric tool into your development process -- one where an employee has to write a book about it's quirks -- sounds like a failure for the guys in the trenches.

On practically every software project in the history of software projects that have lasted more than 3 release cycles, there is a person on the team who could write a _${Some Component}, The ??? Parts_ book. Nobody ever thinks to do that, because _${Our Report Generation Library}, The ??? Parts_ is super boring.

The reality though is that line-for-line, a transpiler is probably not much harder to write than a serious report generation tool. I agree with the commenter upthread, who thinks this is a result of people simply never having tried to write a compiler before.

> It seems like a spectacular success story.

It might be, but for what many would argue are the wrong reasons, maybe even unnecessary.

> This is an internal language designed as an incremental improvement over VB that gave them cross-platform common codebase.

The problem is that at the time, there was already several cross-platform technologies in existence, many of which were being developed in the open. Utilizing one of these technologies would have allowed FogCreek to focus on what they do best, make software. Instead, they took a proprietary uni-platform language and attempted all on their own to make it cross-platform capable - which led to years of maintainability issues.

> It lasted 10 years

They gained an early advantage of not having to throw out the codebase and start over, yet they bought themselves 10 years of technical debt which continued to pose a burden on the small company. Many would argue that biting the bullet early on and switching to an open, community-driven cross-platform language/environment would have yielded much more return on the initial investment.

> When they transitioned off of it, they did it not with a rewrite, but with mechanical translation

Yes, that is an achievement, but again, for the wrong reasons.

I feel like you could take this comment, make very minimal tweaks, and deploy it in any language-war debate. "They succeeded with Golang, but for all the wrong reasons. They gained an early advantage but bought themselves 10 years of technical debt that a more modern cross-platform language would have spared them".

And I feel like when you get to the point where the best arguments you can make against something are isomorphic to the arguments you'd make against mainstream languages in language-war debates, that's a win condition.

Sure, FogCreek thought it was a good idea at the time, but over the years it became a significant burden, to the point they had dedicated staff working on just keeping Wasabi alive. Time was even spent writing an internally distributed book about the caveats of the language!

I know you will dismiss this as "routine", but it's not...

For a small company, this is an enormous waste of time, money, and energy.

A big company like Google or Microsoft can afford to throw developers by the dozen at internal proprietary languages and not even blink -- but according to the article, FogCreek did blink every time they had to dedicate time to fixing it. It took time, money, and energy away from their core business - making software.

That's a lose condition.

FogCreek should have bit the bullet and re-wrote their application in an open, standardized cross-platform system. They would have been able to spend zero time worrying about the language, and 100% of their time worrying about their application. They could hire engineers off the street and have them produce in days-to-weeks instead of weeks-to-months. They would have saved themselves an enormous amount of time, money, and energy invested in a language that is now dead anyway.

It may have seemed like a good choice back when the decision was made, but in hindsight it appears to have been a very poor, short-sighted choice.

> FogCreek should have bit the bullet and re-wrote their application in an open, standardized cross-platform system.

Ah, so you happen to know better than Joel how much resources they had available at the time, how long the rewrite would have taken, how much it would have affected their ability to ship new features?

Fog Creek was a much smaller company back when they wrote Wasabi. Postponing the rewrite until they had more resources to spare was probably a good decision.

> For a small company, this is an enormous waste of time, money, and energy.

I think you have this backwards. A small company that writes a compiler and loses a few weeks of dev time per year survives for a decade, while spinning up various new products.

In another world, a small company rewrites its only source of revenue. 18 months later, they release the rewrite with zero new features and a chunk of new bugs and promptly die, because who's going to buy a product that spends a year and a half going backwards?

I think his point can be summarized as "it's better to have to maintain your software than to have to maintain your software and the compiler for it", which is hard to argue against.

Then again, given that they had the codebase already, writing their own transpiler sounds like it was the best option at the time.

> The problem is that at the time, there was already several cross-platform technologies in existence, many of which were being developed in the open.

FogBugz wasn't written in any of those languages though. And it isn't like Spolsky's "never rewrite from scratch" views are unknown here.

Colossal error vs spectacular success story. Yay hyperbole.

I'd say the actual experience is somewhere in between. Sure it enabled them to support client requests to be cross platform and proved useful for a very long time, but what was the broader opportunity cost? Did supporting this proprietary infrastructure eat up resources and prevent them from exploring other ideas? Probably.

Big projects are routinely ported once or twice to new languages. Normally, moving a project from one language to another entails a full rewrite. Because the process of building their own language had the side effect of instrumenting all their code (the transpiler was custom-designed for their application), they were able to write a program to do the port for them. That's a win I don't see captured in the original blog post, and that's all I'm pointing out.

I don't think it ate up any more resources than, say, MySQL support. Fog Creek employees have produced tons of innovation since Wasabi was introduced, including brand-new companies like Trello (2011/2014) and Stack Overflow (2008), as well as in-house products like Kiln (2008), WebPutty (2011), and Make Better Software: The Training Series (2009-ish). None of these projects were particularly resource-constrained by having to do some compiler and runtime maintenance in the process of building FogBugz.

Thank you for the most insightful comment on this story. I find it bizarre that so many are unable to understand that making the decision to 'kill' wasabi today does not necessarily mean that it was a mistake.

This whole story is a fabulous insight into software development for business over the long-term.

Sure, but success stories only make the people who worked on them look smart, whereas post mortems give everyone a chance.

"It is usually a "colossal error" to write your own in-house closed-source/proprietary language"

I'm curious if anybody on this thread who has written more than three or four compilers/parsers would agree with you.

Depending on the task, the only solution to some problems is to write a custom/proprietary language (whether it's closed source, of course, is up to the company).

> Depending on the task, the only solution to some problems is to write a custom/proprietary language

Is a bug tracker one of those problems?

>> Is a bug tracker one of those problems?

But "bug tracker" is not the problem that was being solved.

The problem was taking a big pile of legacy code and translating it to more than one platform vs rewriting the entire app from scratch in a new language that was cross platform.

It just happened that the legacy code was for a bug tracker, but it could have been for anything.

It is usually a "colossal error" to write your own in-house closed-source/proprietary language, no matter how small or large the language is.

Really?

I don't think so, having done this once, to the great success of the company. They also wrote their own database. The compiler was maintained by a team long after I left the company.

Software is hard. There are more interesting, and hard, problems than pushing the value of a field from one subsystem to the other.

Whereas, complex systems built on popular OO frameworks never have issues with maintainability.

/me deactivates snark mode

I see the issue exactly the other way around.

If you can build a domain specific language that lets you express concepts in a clear way free of boilerplate or conceptual hackery (ORMs, for example) you will wind up with a much lighter maintenance load than the equivalent functionality built on an off the shelf framework.

Of course, there's nothing stopping you from using the two as appropriate. Simple CRUD app? Rails. Need to express a very complex domain in a readable, easily maintained form? Custom language time.

Most things that have lots of reverse-dependencies require a significant amount of maintenance. Compilers are not much different from "common" libraries, or special-purpose frameworks, in that respect. Also, writing a direct-to-assembly compiler is probably not a wise idea.

Reply on news.ycombinator.com