(Since you're answering arbitrary Fog Creek questions) In retrospect, do you think it was a mistake to make kiln hg-centric at first?
(Since you're answering arbitrary Fog Creek questions) In retrospect, do you think it was a mistake to make kiln hg-centric at first?
(Since you're answering arbitrary Fog Creek questions) In retrospect, do you
think it was a mistake to make kiln hg-centric at first?
No; I think it was a mistake to not also support Subversion out-of-the-box.Our customers were overwhelmingly Windows shops, and Git on Windows in 2007 was just unusably bad. It really would not have been a viable option. (I did look at Bazaar and Fossil, which were good players on both Windows and Unix, but neither seemed like a good fit for other reasons.) But Kiln's core value prop at the beginning was actually code review, and I think we could've found a cool way to bring in a Phabricator-like patch workflow that would've meshed just fine with Subversion and given our customers a much easier way to get access to Kiln's goodness. In that world, Mercurial would be a kind of bonus feature you could use, not the only way into Kiln. The resulting product would've been very different, mind, but I think it would've gone way better.
The other three technical mistakes we made, since you didn't ask me, were having FogBugz target .NET instead of Java (given the immaturity of Mono at the time only; I love .NET); having Wasabi compile to C# instead of IL (especially given the previous note); and having Copilot directly modifying VNC and its protocol instead of just jacketing it with a small wrapper app. These three decisions collectively slowed the company down a ton at a time when we shouldn't have let ourselves do that.
I enjoyed working with you, Alex. Glad to see you doing well!
It's a bit harsh but I always feel like Fog Creek might be the cautionary tale in "what happens if you over hire for capability vs. your requirements?" I think that a less capable team would have never landed on the "let's maintain our own programming language" approach w.r.t. Wasabi.
As an aside, I do think that targeting Mono was the right thing to do for the universe, as it butterfly-effected tedu into writing weird and wonderful technical blog posts for the next ten years :p
Databases store stuff really well. If get to the level of needing to configure storage for different tiers of access they can do that, it just takes a bit of work. Of course if your blob data is stored in tables that have OLTP data in them, then you have a bit of work to do to separate it out.
This is speaking from recent experience of having to manage random blobs of sensitive data in s3 buckets that engineers have created rather than bothering to put in the main application data store.
Storing attachments as a blob in a database has all sorts of disadvantages I'm sure you're aware of, but it has the major advantage that if you can see the reference to the attachment, you can fetch the attachment. With links to a filesystem, you have to deal with issues like the frontends can't access the files because they're on the wrong system, or the network filesystem is down or .... There's a lot of possibilities.
As an aside, I do think that targeting Mono was the right thing to do for
the universe, as it butterfly-effected tedu into writing weird and wonderful
technical blog posts for the next ten years :p
I've never figured out whether that work broke him or was simply his muse, but I also do confess to liking the result. So not a complete loss.The original version of Wasabi, known as Thistle, was written in Java, by the intern in the class before Aardvark’d. It transpiled ASP to PHP.
Every intern class was named after an animal with the next consecutive letter. I don’t remember any of them except Aardvark, and I was a “B????” intern!