Fog Creek Software
Discussion Board

Welcome! and rules

Joel on Software

Article on why Fog Creek doesn't use .NET?

I assume there is a good reason for it, but I can't find it amid all of Joel's musings. Can someone point me to Fog Creek's reasoning for not moving to .NET?

Thursday, March 10, 2005

I imagine it is because there is no upside and a world of pain on the downside.

Can you think of anything that would convince Joel to "upgrade" ? I can't, looking at the products he has, and I love .NET, specially ASP.NET/C# for business applications.

Thursday, March 10, 2005

IIRC there is a chapter discussing this very thing in somed detail in Joel's book (the one with the very long title, the exact title escapes me). It's downstairs and I am too lazy to go find it and summarize it.

I know Joel has a big hangup about the CLR deployment issue, as do I.

Thursday, March 10, 2005

What is IIRC? Is there anywhere that Joel has published this opinion on the web so I can take a quick look at it?

Thursday, March 10, 2005

IIRC = If I Recall Correctly.

Thursday, March 10, 2005

Why change a good thing?

Thursday, March 10, 2005

oh never mind...i was thinking in terms of the message board only

Thursday, March 10, 2005

One might imagine that if FogCreek were to move forward with some NEW web app, they might elect to use ASP.NET, since that is supported (somewhat) on Unix using Apache, Mono, and mod_mono.

At least, it would be less restrictive than their current ASP => PHP cross-compiler.

Brad Wilson
Thursday, March 10, 2005

In Joel's book he makes a simple cost benefit analysis to come to his solution regarding wether or not he should rewrite existing ASP apps in ASP.NET.

Cost = high

A large amount of the existing code has to be rewritten because its written in VB and VB.NET and VB6 are largely incompatible.

Benefit = low (zero)

Benefit basically boils down to profit. In order to gain profit, Joel has to get people to buy his software. In order for an activity to have benefit, it needs to induce people to by the software. However, the rewrite does nothing of the sort. It just duplicates the existing features, which were already doing the job of inducing people to buy his software. Therefore, by definition, there is no benefit to the rewrite.

----------      = Return on Investment

here benefit is low (zero), so ROI = 0.

So there is no valid business reason to rewrite the software, because nothing valid comes out of it.

Beyond that, is the risk that while Joel is wasting his time engaging in tasks that don't earn profit, that Fred (joel's competitor) will be talking to Joel's customers, finding out what needs Joel is ignoring, meetng those needs, and stealing away all of his business.

Scott Wisniewski
Friday, March 11, 2005

Scott summed up the rationale for the reasoning behind not rewriting our products (regardless of which language we are porting them to).

We do use .NET though.  Quite extensively.  But right now it's simply for internal software.

Michael H. Pryor (fogcreek)
Monday, March 14, 2005


Are you saying that if FC needs a quick Win32 app for internal use, or perhaps even a not-so-quick (development wise) internal app, you are using Visual Studio .NET and deploying .NET apps internally?

As opposed to something like VB6 or Delphi?

Mitch & Murray (from downtown)
Tuesday, March 15, 2005

Nope, we just use whatever gets the job done the best for us.  That could be VB6, C++, .NET, ASP, PHP, Perl, or a DOS batch script.

Michael H. Pryor (fogcreek)
Wednesday, March 16, 2005

I wonder if they already tried to create a FogBugz.NET using . So that would be ASP -> .NET using their own ASP -> PHP and Phalanger to complete the PHP -> .NET part. If this is any good it could drastically reduce their need for servers in the farm for hosting FogBugz.
Debugging the end result could prove a challage since they are now 2 steps away from the original source.

(copy from ?off thread on a related subject)

Just me (Sir to you)
Monday, March 21, 2005

ROI = 0? No valid business reason to rewrite software? I disagree. 

Unless you are planning on retiring a product, would not the extra time spent maintaining and upgrading classic ASP alone dwarf the ASP.NET rewrite time? Is it not difficult to satisfy rising consumer expectations for the web UI using classic ASP? An ASP to ASP.NET rewrite is inevitable and delaying it will lose you money.

It would be pointless to provide a laundry list of technical improvements. Rather, I'd focus on the internal consequences. Everything about FC is top-notch orientated. How many great employees want to use old versions of development platforms? There's no way I could sit in my Herman Miller chair and think "Boy, it would be really exciting if this was built in XYZ, but it's a legacy ABC app and that's our bread and butter." In 5 years, how do you intend to attract a quality developer to work on a classic ASP codebase?

This is no slam, but Joel -always- throws around how much talent is in FC. Additionally, support for .NET seems to be overflowing. If FC has the talent, why avoid rewarding hurdles? The monolithic company attitude to settle for what currently works, instead of what's best, doesn’t seem to fit.

Thursday, March 24, 2005

*  Recent Topics

*  Fog Creek Home