Joel Spolsky and Jeff Atwood chat about StackOverflow.com in their third podcast.

Spolsky:    Hello!

Spolsky: Oh wait, I just got a picture of... who's that?

Atwood: It's Ogre from the movie Revenge of the Nerds.

Spolsky: Is that that guy who was in A Weekend at Bernie's?

Atwood: He's possible, he's a character actor.  But that specific movie is Revenge of the Nerds, where he screams "Nerds!"

Spolsky: Got it.  Everybody's favorite movie.  Alright, so we're coming to you today on the StackOverflow Podcast #3.  Hopefully better sound.  We're recording this using Skype Fand Pamela for Skype, which is a little $20 program that you buy and you add it into Skype and it lets you record those conversations and should allow us to play sounds and you know what? I got rid of all that audio equipment that I had here on my desk.  All those mixers and stuff that Leo Laporte and Adam Curry convinced me were necessary.  I don't think they're really necessary.  I think we're just going to record this using software and then I'll use a program called Levelator, which will basically adjust the levels on the file that we generate so that we all come out at the same volume.

Atwood: Yes, there was growing amount of unrest about the difference in volume levels.  I think people were perceiving it as a slight, which ended up having difficulty in hearing me.

Spolsky: And I don't quite know how much Levelator will really work, because sometimes one person has a lower voice or a more bass-y voice, it might sound like they're at different levels even though they're not technically at different levels.

Atwood: Right.  And Joel, what kind of headset are you using?  Anything fancy?

Spolsky: No, I just have a plain old Plantronics headset - not the USB thing.  The advantage of that is that then I can plug them into this little switch to switch between the speaker and the headset.  Basically, when I'm not talking on the headset, you want the sound to go out the speaker, otherwise, you don't hear it when your computer rings.

Atwood: Yeah, I'm using Plantronics, but I'm using their USB model, so it shows up as another sound card.  But what I like about that is that you can configure applications so that they specifically talk to the headset, like Skype for example.  So you get this nice segregations of sounds between outputs.  It's pretty cool.

Spolsky: That makes sense.

Atwood: It's also very very clean, cause Windows detects it and it automatically works and it's really pretty nice.  So I do recommend USB headsets as a general rule.  Easier to deal with.

Spolsky: That'll be the next iteration of this.  We should probably not make this a podcast about podcasting I think.  Probably the first three episodes of every podcast in the world are about podcasts.

Atwood: Yeah, well I think we're just trying to iteratively improve what we're doing.  We just want to make sure people know that A) we're listening to their feedback and B) acting on it.  That's all.

Spolsky: That's right.  So what's new?

Atwood: So let's see.  Some new things.  I had a few things left over from last week that I wanted to talk about, we didn't get to.  One of them, and these are largely based on the feedback that we got off the initial post that you and I both did on StackOverflow.  One of them, I kinda covered on my blog, was the "Are books dead?" theme.  A lot of people got that out of your post, your initial post.  Cause you started very provocatively with saying software developers don't read books any more, which is largely true, but there are some caveats around that.  And when we talked about doing StackOverflow, we believe it's going to be complimentary to what I call classic programming books, books that teach you how you should program and why you should program.  The theory of programming rather than "Here's how you do this in Ruby." or "Here's how you do this in Java."  Now those kind of books I love, and we feel that StackOverflow fills a niche that those books don't fill, which is namely the immediate gratification that we expect of programming:  You have a problem and you want an answer to that problem.  And that's what StackOverflow is really about.  And actually, you know Joel, it's funny, when I started my blog, I literally founded it on the idea of these classic programming books that I wanted to read and share with people cause I didn't have an outlet for that in my current place of employment at the time.  And I never found your - you had a recommended reading list and yours and mine are really similar.  There's a lot of overlap.

Spolsky: There were two reading lists.  One was a really really long time ago.

Atwood: 2002.

Spolsky: Yeah, God, I think the original version of that might have been 2000.  That might have been something that I did really early on.  Just because I was getting so many questions saying "Well, what should I read next?"  I don't even know what to say any more.

Atwood: You just point to your blog post.  I had an e-mail conversation with, and I'm probably going to mispronounce his name, is it Steve Yeikky?

Spolsky: Yeggy.  His friends call him Stevey.

Atwood: But I had an e-mail conversation with him cause, do you remember, Joel?  I remember.  It's weird how you'll write stuff and I'll focus on little phrases that you've written.  And one of those phrases that I've always focused on, you were sort of a relatively early adopter of the Mac and one of the observations you made is that you found the font rendering really screwy.  And I thought that was interesting and I never really understood what it was about, until I downloaded Safari.  And Safari, on Windows, is unique in that it thrusts you into the world of Apple's font rendering.  Like they literally ported over Apple's font rendering lock, stock, and barrel.  So I was looking at the font rendering going "What happened here?" You know?  And I went back to your post and then I wrote a post about it and I wasn't necessarily saying it sucked or anything, but I wanted to understand why they made that choice.  And it was good because I learned so much from that and you actually had a follow-up post about explaining "Do you favor the font designer like Apple does or do you favor the pixel grid like Microsoft does?"  Not that one is more right than the other, it's just understanding the choices you make, which is true in so many things in programming, right?  It's not like there's the One Right Choice.  It's understanding all the trade-offs involved in your choice and making the appropriate one.  And Steve Yeggy just discovered that.  I don't know if you saw his post, but he's like "I was in an Apple store and I saw how great the font rendering was and I can actually can read it from a distance and I decided that Apple just renders fonts better." And so I e-mailed him, basically, links to my blog post and I felt kind of guilty saying "hey Steve, I don't really want to talk to you I just want you to read my blog."  But I felt that it was really helpful so that he could get a sense of why he had that perception and what's going on there.

Spolsky: Yeah eventually people figure it out.  I honestly don't even think that the people working on typography at Microsoft or Apple are even completely necessarily aware of what they are favoring and why their font rendering is so different.  And for any listeners who are listening who didn't follow the whole discussion, Microsoft had this ClearType group that actually specifically designed some fonts that were designed for screen legibility.  And that meant that the font itself was designed to fit in the pixel grid and Apple has never done that.  They've always taken print fonts and they've used anti aliasing to just kind of approximate and it just doesn't quite fit in the pixel grid so well.  And so it does come out blurrier but it is truer to the underlying font.  Certainly if you are doing design work for the printed page there's a huge difference between these fonts on the printed page where you have 300 or 600 or 1200 DPI that you don't get on the computer screen where you have at best 96 DPI.  The truth is - for computer monitors - there are really only four or five possible fonts that you can see the difference between unless you really do this Apple style anti aliasing.  At smaller fonts at like around the 9pt, 10pt size on Windows all the sans serif fonts look like all the other sans serif fonts and all the serif fonts look the same and you can barely tell the difference.  And the difference is that Apple's way of rendering those you can sort of see the difference in the general weight, the feel of the paragraph of text, does it feel crowded or spindly, does it feel heavy or light, and how dark is a whole paragraph of text.  That's something that Microsoft's fonts never preserved because they've all been hammered into the on screen 96 DPI or 72 DPI pixels.  The other difference is sort of a long time difference which is that traditionally Apple did have 72 dots per inch and Windows had 96.  So pretty much Apple had to use forms of anti aliasing to show you anything.  They truly had blurrier fonts for a long time.

Atwood: Yeah and the other thing I liked in your response to that was that you pointed out that people, and you see this too in programming languages as well, people like what they are used to, right?  There's certainly an aspect of I grew up with this or this is how I learned to do it or this is what I've always seen so this is what I like.  And I think that is why as a Windows user being used to ClearType, which I think ClearType is excellent, seeing Safari's rendering I was like "Oh my God, my eyes are going to bleed from the weirdness of this font".  I think that if you saw it everyday on the Mac side you would grow used to it and say ok this is the way a font should look and I've heard people describe ClearType as quote "spindly."  Because it is hammered into the pixel grid so it doesn't blur over it is very rigid, it's very tight, aligns very sharply with the pixel matrix.

Spolsky:     Yeah, when you have a line of text, imagine a horizontal line that's a part of some letter, it's either gotta be one pixel wide or two pixels wide, and those are you're two choices.  Whereas on the Mac, it could be a pixel, and then the pixel to the right of it could be a little bit grey, to imply that it's a little bit wider.  And obviously the sub-pixel rendering as well, where they're turning on and off the individual red, green, and blue sub-pixels--so every pixel has got a red, a green, and a blue element that can be turned on and off independently.  So anyway, yeah, I think it really is sort of a little bit subjective, it's a little bit what you're used to, and it's just wrong to try to use--or, you're almost guaranteed to not be well received if you use Apple rendering on Windows or Windows rendering on Apple.  It's just gonna make you look foreign, strange, and badly ported.  And, I believe somebody told me it may be possible in Safari--I haven't tried--to turn off the Quartz rendering and use the native rendering for your fonts.  Not a hundred percent sure if that's possible, but if I were Apple, that would be the default, because there's no reason to have people just not liking your web browser just because it appears arbitrarily different.

Atwood:   So one of the cool things about--I think Safari's actually a fantastic browser, I have a very deep respect for what the WebKit team is doing.  I think they're really innovating in ways that Firefox isn't, and certainly IE isn't.  But I agree that they should back-port that, and in fact they have.  They announced their latest, on what they call "nightlies".  You can actually switch to the Windows native method of font rendering, which I thought was very nice.

Spolsky:     Cool, yeah.  And that should just be the default, 'cause they're just gonna get yelled at on Windows, even if they're right.  It doesn't matter, it's just sort of like, y'know, walking into a restaurant in Rome and shouting loudly in English.  You're just gonna aggravate people.  "Speak Latin, dammit, this is Rome!"

[12:01]

Atwood:   Yeah, but you know, font rendering is neat, because it's very computer sciencey.  Like certainly Knuth spent all those years working on his, y'know, TeX, LaTeX, or TeX layout engine, where he was gonna, "Oh, I'm gonna write a programming book," and then he got distracted for like five to seven years,

Spolsky:     I thought it was, like, fifteen or something.

Atwood:   All these technical issues in computer science on how to lay out the printed page.  It's really, really fascinating.  And is there anything more fundamental than font readability?  It's really, really fundamental to readability.  And what do you do online, all day?  At least when I'm doing this, the time is just read, read, read.  So I think these are really important issues, and it's really fun to understand them.  I think it's very helpful.  I think it's very germane to programming.  Because sometimes people will criticize my blog and say, "What does this have to do with programming?"  And I would say, if you think about it, this has everything to do with programming.  I don't view programming as the act of typing in code and compiling.  It's so much more than that, and I think this is a good example of that, and I found it fascinating.

Spolsky:     Cool.  OK, so fonts.  Do we have any to-do's on the to-do list to cross off there? Any agenda items? No? What's next?

Atwood:   No, no.  We do have a server now, a dedicated server.  I want to talk a little bit about the technology stack we're going to use.  Now this ties back to another theme I saw in the Reddit comments to your post and my post.  We are going to be language agnostic in terms of the actual site itself.  This is not a Windows developer site, necessarily.  We're gonna really encourage an open kimono policy of, if you're programming, and you have a question, or answers, then that's what StackOverflow is about.  We're not going to segregate, "This is the BASIC programmers' ghetto," right? Or, "This is the really cool guys who know C."  And by the way, I've gotten so much crap about the fact that I don't know C now, thanks to you and your curiosity.

Spolsky:     [laughs]

Atwood:   So I hope that makes you happy, I get a lot of crap about that now.  I don't know pointers--

[14:02]

Spolsky:     Are you gonna learn C now?

Atwood:   Yeah--well, no I, I dunno.

Spolsky:     C'mon!

Atwood:   To me it's like, should I go spear-hunting--

Spolsky:     All the cool kids do it!

Atwood:   I just feel like I'm gonna be spear-hunting for my own food now, instead of going to the grocery store, by worrying about this pointer--

Spolsky:     Well, let me ask you this: should you ever do something that's not the most practical way to do something?

Atwood:   Well sure, I mean, that's not a real question, is it?

Spolsky:    Well, yeah, because your argument was, "It's not practical to use C, so should I do that? No."  And I'm just saying, well that's not a valid argument.  It's not actually the case that, just because C is not practical--Although, y'know, we got some pushback from that.  There's millions of systems, yes, I know, the Linux kernel is written in C, there's lots of existing legacy code that's written in C, and there's future code that is, and will, and should be written in C.  And I sorta made an off-hand comment in one sentence, which is that C is almost never the right choice for a language for a new coding project. But y'know, we were talking about the millions of types of code that somebody sits down to write in the world, and only a small percentage of those is C the right choice.  But that class still exists for which C is the right choice.  But that's it, I mean, you know it's true you could say "I want to be very pragmatic, I'm never gonna have any use for this, why should I learn this? Or why should I do it the hard way once?" But I think what all of those of us who are giving you grief are trying to tell you is that the process of doing that, whether or not you like it, you're gonna learn some fundamental things that--Y'know, we see C as being--it's not quite like teaching Latin, in which the effort--y'know Latin is taught in the high-schools in order to teach you to be logical and rigorous, and in order to think about things that are difficult in a particularly logical pattern, teach you a way of thinking.  And I don't think that's exactly true of C.  I think it's more true just that it's a language that basically, it sort of reveals directly certain underlying and important concepts of computer programming, that are kind of crucial.  It's sort of like the difference between an automatic and a manual transmission in a car, that it's true you can always find an automatic transmission, and I wouldn't tell you to go learn how to drive a manual in case one day you're caught and the only car available is the WWII era Jeep, and you need to drive around in that, so you wish you had learned how to drive a manual transmission.  But what I'm really telling you is, learn how to drive with a manual transmission so you understand gears, and you understand gearing ratios, and you understand low and high gears, and you understand that fundamental relationship between torque and speed.  I don't wanna beat this C/C++ issue into the ground.  But, the server, you were talking about, we have a new server, that's what we were talking about.

[16:57]

Atwood:  Yep, yep, so we have a dedicated dual quad-core Windows Server 2008 64-bit server from CrystalTech, and that's all good to go.

Spolsky:  [joking] How could you possibly use Windows, good Lord, man!

Atwood:  Well, that's what I was gonna jump into. So, one of the reasons I'm using Windows, even though StackOverflow the site will be absolutely language agnostic, and decidedly so--that's one of our stated goals, is to be agnostic about language--we are not personally going to be--

Spolsky:  Except Lisp.

Atwood:  [laughs]

Spolsky:  Lisp users are not welcome, under any circumstances.  But apart from that, we're going to be completely language agnostic. [laughs]

Atwood:  We are not personally going to be language agnostic, because we need to actually build the site.  And in terms of people actually working on it, Joel's in an advisory role, I'm gonna be writing code, and then a friend of mine, Jarrod, I'll be working very closely with.  So it's sort of like 1.5 developers, so I need to actually get things done.  In order to do that, I'm gonna fall back on what I know, and what I know is essentially ASP.NET.  So ASP.NET is gonna be the platform.  And I actually really like ASP.NET.  There's things I don't like about the stack, like the webforms model, and so on and so forth, but as a core programming environment, I feel like it's more than up to the task, quite a bit of tooling around it that's gonna help us out.  So I'm looking forward to that.  I just want to get that out of the way early on as far as like technology choices.  And also to segregate and say again, what we build the site in does not equate to what the ultimate StackOverflow site will be about, in the end.  Technology choice doesn't matter.  And Joel, you know that more than anybody else, with the whole Wasabi thing, right? Like--which I've come full circle on, I used to be very critical of that--and now I've decided, it doesn't matter.  Because unless you're open-source, nobody's gonna actually see your--

Spolsky:   Ahh, it does matter, you see, because Fogbugz was written in Wasabi, and therefore we were able to port it to .NET in, y'know, about a month of work.  And so Fogbugz, as of today, is actually running on .NET, which means it runs on Mono, it's a lot faster than the old VBScript/PHP version.  So, having control of our compiler has actually really paid off.  And we've got some features in Wasabi that aren't in C#, that aren't in any other kinda off-the-shelf language we can use, it's really nice.

Atwood:   No, I mean, to me it's like, I don't care if you guys are using black magic at this point.  As an external consumer--I mean, if I was working at Fog Creek, I think I would have more deeper concern about what we were programming in--but as a consumer, who cares, right?

Spolsky:   Right, that's true, they shouldn't--they don't--y'know I've seen a competitor of ours who will remain nameless, actually advertising that their product is built in Java, as if this was a reason to buy it or not buy it.  And I don't think anybody buying software really cares, except for a very few, shall we say, teenagers, who are still kind of in their throes of religious fundamentalism, or flag-waving-ism, or whatever it may be.  And they've decided that you're part of the enemy camp, and therefore they don't want to use your product, because you're the enemy, because you're insufficiently hateful towards Java or Microsoft or PHP or Lisp, or whatever the case may be.

Atwood:   Yeah, and one final thing before we get into the listener questions.  I think that covers the logistic side, so I want to cover first, and somebody made a comment asking if I had "jumped the shark by osmosis" now that I'm working with you, which I thought was very funny, and also referencing that original post I made about the Wasabi thing, where--

Spolsky:   OK, so what is, exactly, "jumping the shark"?

Atwood:   So, jumping the shark is based on a Happy Days television show.  The Fonz--remember that character, "hey, the Fonz," on Happy Days?

Spolsky:   Yeah, sure.

Atwood:   So, in the later days of Happy Days, when it was sort of--the show was falling apart, not being as popular--first they added a little kid.  That's a thing, a lotta times shows will do that to sort of bolster the ratings, y'know, "Oh, look, we added a cute little kid--"

Spolsky:   Is that Chachi?

Atwood:   No, I think the classic example is Family Ties, that Michael J. Fox show, they added a little kid to that show at the end of its life.

Spolsky:   Isn't that Leonardo DiCaprio?

Atwood:   Gosh, I don't even remember.

Spolsky:   That was Leonardo DiCaprio!

Atwood:   Yeah, so that's one of the go-to devices.  And the general term for a show that's falling apart, not popular anymore, at the end of it's lifecycle, but desperately wanting your attention, is "jumping the shark."  They'll do something just ridiculous to get your attention.  And in this case, in Happy Days, it was the Fonz jumping a pool containing a shark on his motorcycle.  And he was actually wearing shorts, too, which--the Fonz wearing shorts just doesn't compute.  Would the Fonz ever really wear shorts?

Spolsky:   No, I think he had to wear jeans at all times.  It was a law.

Atwood:   Exactly, exactly.  So yeah, that's what the "jumping the shark" reference is about.  E.g. your popularity had flagged, so you're trying to get attention, et cetera, et cetera.  That's what that was about.

Spolsky:   Oh, I see.  "Tonight, on a very special Joel on Software," in which I become addicted to something and recover from it, all one 22-minute episode, 30 minutes with commercials.

Atwood:   Right, no, I feel a little awkward about that.  It's a lot easier to criticize someone over the web, than it is directly to their face, by the way.

Spolsky:   Yeah. [laughs]

Atwood:   But, y'know, at the time I really was kind of upset about this, because people misunderstand, and they think, oh, you're just doing this to get ratings, and let me--that is absolutely not true, like the thing I did with Paul Graham, the thing I did with you, I was really, on some level, really offended by that information, it really bothered me.

Spolsky:   I think a lot of people were offended that we did Wasabi.  And I think personally, the reason I believe--I mean, you can tell me if it's different in your case--but personally the reason I believe that is I don't think the average working programmer--and by average I mean, y'know, the majority of programmers, understands how easy it is to build a compiler.  And that that is--because, pretty much anybody who has done a computer science degree has taken a course in compilers, and knows how to sit down and write a compiler.  Or maybe it's only the good computer science degrees? I have no idea.  Seems to me like that's sort of one of these things that you kind of learn to do, just like, if you're gonna be a chef, you learn how to make a risotto.  It's not that hard.  And a lot of working programmers that are working, shall we say, higher up on the stack, where they're building applications and software using these great and exciting tools that somebody else gave them.  And for them, building their own tools just never really entered into their imagination of the realm of possibility.  So I think that if I had said, y'know, we build our own desktop computers, we buy the boxes and motherboards, and we snap it together ourselves--which we don't--but if I'd said that we did, would anybody be as offended? Y'know, maybe not, they'd be like, yeah, I can see how you would do that, it's not that stupid.  But a compiler, to many people, I think a compiler is such a dark mystery as to how that thing could possibly work, and what it could possibly do, and why would you ever make your own? So I think a lot of people were a little bit shocked by that.  A lot of people also--y'know, I don't always phrase things as well, and then I actually introduced Wasabi in a two-part answer to a question that a friend of mine asked me.  And a friend of mine asked me what application he should be doing development in, what programming stack, basically, .NET, Java, PHP, whatever the choices were, and it was sort of a major new project, and it was very mission critical for them, and I do have to say that it was sort of, in some sense, enterprisey.  Whether that's a good thing or not.  In other words, it was not the kind of thing where they wanted to give people, y'know, do the latest and sexiest thing.  They really just needed to get their work done, and they needed it to work, and they needed it to be reliable, and they couldn't be messing around with a stack that didn't have--they didn't want to be tweaking their stack all day long, or messing around with their tools.  They just wanted reliable tools that did what they needed.  And he sort of said, y'know, what should I use, and then he said, what do you use?  And I answered both questions in sequence, y'know I said, it doesn't matter: if you use the Java stack, that's fine; if you use the ASP.NET and the Windows stack, that's fine; if you use--I don't even know if I said anything about PHP.  I think I said Python is just about ready for prime-time, which I still feel, and Ruby is not quite ready for prime-time, which I still feel.  I think that Ruby is--y'know I'm gonna be speaking at the RailsConf--so Ruby is wonderful, you guys, it's just great, it's totally ready for prime-time.

Atwood:   [laughs]

Spolsky:   No, but honestly, there are people that are running into deployment issues with Ruby.  I think that Twitter is not as stable as it should be, and I attribute some of that to Ruby.  I've seen some failed projects, and some projects that have succeeded, and that will not always be the case.  And Ruby has enormous strengths, and enormous advantages--it's also got some disadvantages, like in terms of performance, that have not yet been fully solved.  And I don't see any reason why they won't be, but they haven't yet.  The difficulty of deployment, that kind of thing.  I'm not such an expert on it, I'm not a deep Ruby programmer.  I know Ruby, but I'm not an expert on it by any means, I've never written any major applications in it.  But I can tell you just from just listening to the people that I work with and my customers who use Fogbugz, and the people that I talk to all day long by e-mail or on my website, that there are just too many cases of Ruby being not quite ready for prime-time.  Which doesn't mean--it just means for his application, it wasn't there.  So, I'm being too defensive there, but basically--and also, don't forget this was when Ruby on Rails was less than a year old, I think.  And then I answered his second question, which was "what do you use?" and I said, well we use Wasabi, it's a custom thing.  And then some people saw that and said, "Oh my God! You're saying that Ruby's not ready, and you're using some wacky--"  Y'know our situation is very different.  We are the kind of people that love to tinker with our stack, we like to make our own tools.  Every single programmer at Fog Creek is smart enough to write a compiler in a week.  So for them to just edit the compiler and change the compiler is easy.  If the compiler doesn't work the way we expect it too, we fix it.  We don't really care.  So for us, actually, using a crazy language like Wasabi that nobody else is using--as long as it gives us access to the .NET libraries, which it does now, and as long as we control every aspect of the compiler--that's actually safer for us than using Ruby, where if anything happened, we'd be at the mercy of somebody else's compiler.  I mean, I guess we could fork it and try to fix their bugs, but I'd rather have the complete control over all aspects of the technology that I use.  So some people thought that that was hypocritical, for me to be dissing Ruby on the one hand, and yet advocating the use of an even more ridiculous language, which isn't even published.  I mean, you can't even get it.

[27:55]

Atwood:  Right.  But I think, to me, it boils down to, you guys have a business, it's essentially closed-source.  As long as the product works, and people are happy with it, I don't care if you guys are using COBOL.  So that's the realization that I had.  This is an entirely internal thing for you guys, and exposing it doesn't ultimately matter.  And I think that's great.  What I was concerned about, though, was the idea that--if you've worked with developers at all, you've worked with developers that love reinventing the wheel for no good reason.  This is a very, very common failure pattern.  So my concern was, they would read "Well, Joel Spolsky says that we should be writing our own language." And they would go off and write hundreds and thousands of the crappiest languages you could possibly imagine.  Despite what you said earlier, I think it does take quite a bit of skill to do these things well.  Like, if you compare PHP, the language, with C#, the language, you can see there are some problems with this model, right? 

Spolsky:  Yeah, yeah.

Atwood:   Like one has a master language designer behind it, the other has thousands of just random people, and you can really tell.  So that was my other concern: people would read that and go "Oh, I'm gonna create my own framework, create my own everything," and it's all gonna be crappier than stuff you could just go out and get, that would work so much better.  That was my concern.

Spolsky:  That's true. 

Atwood:  So, y'know, it works on, I think, several different levels.

Spolsky:  That is true, and in fact, honestly, if we'd been starting from scratch, Wasabi would never have been the strategy.  The other thing that's very unusual about the Fog Creek case is that we had an existing body of code, of legacy code, basically, that was a large body of well-debugged, wonderful code that I didn't want to give up on, that had taken years and years to develop, that we needed to continue working, and we didn't want to have to rewrite all that.  So if it's a choice of rewriting, let's call it 20 developer years worth of code in a new language, versus spending a couple of months and writing a compiler that can interpret that old code, and maybe add some features.  So what we actually had was this old VBScript code, and that goes back to a time when Fogbugz was developed, and there weren't great alternatives.  Y'know, it was years before .NET, years before Rails, years before--I mean, it was long time ago, when VBScript was actually not a bad choice.  Even before PHP.  And we always had the criteria of--because we have to run on our customers' servers, we want to have sort of, the minimum runtime requirements.  We don't want to tell them, "and then you have to install this piece of this other stack."  In particular, we didn't want to have to tell them to get a Java Virtual Machine up and running, because that's not easy, and they're not really a hundred percent compatible.  We just wanted to be able to throw it on IIS or throw it on Apache, and have it run.

Atwood:  Right.  And again, I think the relationship between you and your customers.  If you guys are happy, and your customers are happy, it literally does not matter what I think.  And I think that is the iron-clad important message to get out of that.  It's your business, as long as everybody's happy, then why not?

Spolsky:  Well, on the other hand, it's not fair to say all blog articles which in any way try to second-guess what anybody is doing in any company are inherently invalid because it's between them and their customers.  You're certainly welcome to try and second-guess what a company is doing.  On the other hand, it is also true that people who criticize decisions that Fog Creek takes based on a couple of blog posts should realize before they criticize that those blog posts are mere snapshots as to what is going on here internally, and that, if there's a debate that happens at Fog Creek about how to do something, or what technology to use--y'know, in the case of some of the decisions that we made about the future directions of Wasabi, that was a two-day offsite with nine people where we went out to the Hamptons and we made marshmallows and hot chocolate and spent two whole days discussing how we wanted to do--how we wanted our technology platform to evolve.  And if you had been there, and you come to a different conclusion, that's one thing.  But to then just sort of read a blog post about it, or just to hear what I just mentioned about the two days, and immediately go off and write an angry blog post about the crazy people at Fogbugz/Fog Creek, and they don't know what they're doing, and so on and so forth.  Well, you have to recognize that you're probably missing some of the information that we had when we made that decision.  We're not necessarily stupid--although it's possible that we're stupid.  And it's just as likely that the outsiders are just a little bit misinformed.

Atwood:  Well, I think sometimes that's why people don't publicize a lot of the internal things that they're doing, for that reason, because of the misinterpretation and the lack of context.  So, one final thing before we get--I do want to get to some questions--we do have a logo design contest that ends, I think, today.  And I want to thank Paul Annesley of 99designs for sorta hooking me up and getting me sorta into that community.  But I've been really pleased with a lot of the logo submissions.

[32:47]

Spolsky:  Yeah, those are some pretty awesome logo submissions.  I don't know--I mean, you and I probably bring a lot of publicity to those contests.  Although--you, because I don't think I mentioned it. The amount of publicity that it has brought to those contests is probably relatively high.  Now I have a question--when you pick one, is that it?  You gotta pay the $512, and that's the logo that you get?

Atwood:  Yeah, as far as I know.

Spolsky:  The way it works with some the commercial ones, like LogoWorks, you get five different designers, or however many, depending on the package you choose, and they design the initial version, but then you can just sort of ask them to tweak it again and again and again, and you can just sort of modify it into something different.  Or you can tell them "I want this part of this, and this part of that," and you can basically go over several other iterations, like, "I love this design, but I think the colors need to be a little brighter, or the colors need to be a little darker, or get rid of this drop-shadow, or use a different font".  So 99designs doesn't have any kind of concept like that?

Atwood:  It's a pretty loose relationship, but I'm gonna be sucking up tremendously to the winning designer, because I really want to have a little bit of an ongoing relationship, for little tweaks like that.  So we'll see what happens with that.  One of the complaints I read through Twitter--I posted on Twitter that I was doing this--and I think some people were kind of offended, designers were offended by this process, they felt like it cheapened the craft, because there were all these people submitting designs that weren't necessarily getting paid, and so on and so forth.

Spolsky:  Yeah, it's sort of a winner-take-all.  The truth is, I'm very sympathetic to that, because these contests are sort of winner-take-all systems, where one person out of a hundred gets paid, and 99 people do work and don't get paid.  And I suspect what may be happening is that the designers who participate in these logo contests have their set of five logos that they designed, and they're just going to keep throwing them up for every single contest that seems even remotely relevant, with a little tweak here or there, and just hope to eventually hit one.

Atwood:  I agree with that, and one thing that's kind of cool is that Leon Bambrick of TimeSnapper--which a really cool sort of record-what-you're doing Windows time-tracking software.  It literally takes screenshots, builds a timeline, and a tag-cloud of what you've been doing--offered up some licenses.  So for the second, third, and fourth designs, I'm gonna be giving them TimeSnapper licenses, courtesy of Leon, who--it's very kind of him to do that.  So I'm gonna reach out to the people who didn't quite win, and give them something, which I think is nice.

Spolsky:  Yeah, I think also, the way the world works with graphic designers, there's sort of a real tendency--once you've been a graphic designer for a while, you've probably had some client that tried to get free work out of you by asking you to submit a design, or to do some work, basically, for free, and then, if we like that, we might hire you back.  And there's a lot of cheap and evil clients that will do this just to try to get free work out of people.  And so there's sort of an understanding around graphics professionals, graphic designers, illustrators, photographers, and so forth, that, that's why you have a portfolio.  You have a portfolio so that the client can decide whether to hire you, but if they hire you, they've gotta pay you for your work.  Whether or not they use it, whether or not they like it, you have a right to be paid for your work.  So I think that's why--I feel that's probably what they're reacting to.  

Atwood:  No, and I agree, there's definitely concerns, but my hope is that the people entering the contest are not--this is basically a day's work.  So, somebody, for a day's work, is getting $512.

Spolsky:  Not even a day's work.

Atwood:  Yeah, and my thinking is, OK, you're taking a chance, you're not putting too much effort into this.  This is iterative, kind of brainstorming kind of design.  You're not gonna spend a week coming up with this comprehensive--

Spolsky:  So we had, what, like 250--

Atwood:  It's over 200, I think it's 220 or so entries.  But a lot of them are derivative, a lot of them are just--and some of them are really bad.

Spolsky:  So they're getting $2 on average.  The average person can expect to make $2. [laughs]

Atwood:  So, not all work is created equally, and not all income is distributed equitably, this is just the way the world is.  So hopefully if you entered the contest, you knew what you were signing up for.

Spolsky:  Oh yeah, and as long as they know what they're signing up for, that's fine.  I suspect that people probably won't do this too much unless they start winning a lot more often, and I think probably the average contest will have a lot fewer entries than ours, because they won't have you publicizing it.  But, the ones I liked, in terms of the logos, what I was looking for myself was what a stack overflow really is.  There were a lot of people that kind of had this idea of something toppling over, or spilling over, or falling over, and that's not really what happens in a stack overflow.  I mean a stack overflow is all about overwriting something.  In other words, you've got this stack, and it's growing, and it continues to grow, and it doesn't fall over, it just overwrites something important.  And nobody really quite captured that.  Some people did at least capture the idea of a stack that grows too high.  And there's nothing wrong with the overflow metaphor.  As it is, I don't think anybody's really going to object to it, it just doesn't really--to a programmer that knows what a stack overflow really is, it's sort of weird.  It sort of looks like a graphic designer's impression, based on what the word overflow means in English, rather than a computer scientist's impression.

Atwood:  You're not going to like what I'm about to say--

Spolsky:  No.

Atwood:  --but I believe that most of the people reading StackOverflow ultimately, longer term, will not understand what a stack overflow is anyway.

Spolsky:  [laughs]

Atwood:  So I think it's--

Spolsky:  It's that error message you get when you try to write C code.  [laughs]

Atwood:  [laughs]

Spolsky:  "I don't know what it means.  It's like, run your program, it's a stack overflow."

Atwood:  People submitted a very funny AMIGA--the AMIGA had this very funny guru meditation error message, and somebody submitted a stack overflow in that format, which was very amusing.  So yeah, you're right, a lot of programmers have seen stack overflows in terms of the error, right?  You do too much recursion, right, or you forget to exit your recursive loop, and your stack overflows.  So I think they're familiar with the error message, but the actual technical underlying details, like details of C, I think are gonna be lost on a lot of people, for better or worse.

Spolsky:  I think it's almost always an infinite loop.  It may also be caused by just  a limited size stack, and you're trying to put too many things on the stack.  But 99% of the time you see it because you're in an infinite loop.

Atwood:  Right, no, that's a great observation, and I'm very glad that we covered that.  So, how many questions do we have this week?

Spolsky:  As many as you want!

Atwood:  OK, we're a little long, so we wanna be careful. So let's go ahead and get on to the questions.

Spolsky:  OK, let's see what we got here.  Let's start with Dave in Vancouver.

[39:25]

Dave Kauffman:  Hi guys, this is Dave Kauffman, sending in from Vancouver, Canada.  Joel, it's great to hear the sultry tones of your voice on the podcast, rather than just written, so I'm looking forward to supporting the podcast and hearing more episodes.  Here's a question--

Spolsky:  Dave is somebody that I know from, I guess he worked at Creo-Cytechs, which is a publishing software company in Vancouver.  I don't know if he's still there, maybe he'll tell us.

Kauffman: --for you.  I think you've written before, and I tend to agree, that computer science as a science in universities is quite inappropriate.   That is, people want to really study the science of it are very in the minority and need to be at universities.  But for the most part, we want good practitioners in the craft of software development, and software engineering.  And that may not be the right place for them when they're trying to find theoretical backgrounds for things that are heuristic.  So my question for you is, is there any real-world use for recursion, or is it just kind of one of these kind of made-up, interesting things that should stay in academia?

Spolsky:  Well, there's definitely a use for recursion, it's just not as common as you may think.  But when you're writing a compiler, you definitely need to know how to use recursion.  

Atwood:  Yeah, it's an unusual choice, I think, in mainstream programming.  I think it's definitely something you want know about and understand.  I think more so than pointers, certainly.  I think that recursion is a very fundamental concept that programmers need to understand.  But yeah, I think it's less common in the wild than people who practice computer science--

Spolsky:  Somebody who's working in a typical insurance application top-level, is unlikely to ever need to recurse.  Although you might, if you're getting some data in an XML format, and you need to kind of, things can include other things--you may have to write some recursive code, you probably will.  I'm willing to go so far as to say that recursion is a fundamental concept.  On the other hand, there's a lot of stuff in computer science, like lambda calculus or even linear algebra--which is often taught as a part of the computer science curriculum--synchronization primitives, that you're probably not ever going to use, that are just a little bit too theoretical.

Atwood:  There's also this big divide--and you also spoke at this Canadian conference that I was invited too, CUSEC, and one of the things I found out there was, there's a huge controversy in Canadian universities about computer science, as a discipline, versus software engineering as a discipline.  I don't view them as different, but they have a set of terminology and a set of classes that are specific to those two things, and it's hugely controversial.

Spolsky:  Well, there's no question that they're different.  Computer science is a field of academic study that has pretty much been unchanged since the 70's--I would even go back to the 60's in terms of the core curriculum--that is an academic course of study that in liberal arts institutions is intended not necessarily to be preparation for a career in programming or in software engineering or software development, but to be an academic discipline of its own right, with its own set of important things that you need to know and results, and the kinds of things you do in computer science include proving theorems, proving that programs never halt, for example, stuff that was relevant to what computers were used for, maybe in the early 70's occasionally, but honestly are not really related to what a software developer does today.  So I disagree, I think that computer science is a reasonable preparation for a career as a software developer, and especially if you go for the whole idea of liberal arts, that you're going to a university to learn a lifetime worth of skills that are generic skills you'll be able to use everywhere, then computer science is a pretty good way to learn how to be a software developer.  And for all practical intents and purposes the elite of software developers generally have a computer science education.  Not always, but often.  That's very, very different than software engineering.  The stuff in software engineering that probably every working programmer should learn.  How to design user interfaces that are easy to use, for example, is something that has almost nothing to do with computer science, and is not a part of traditional computer science, and should be a part of every reasonable software development or software engineering curriculum.  

Atwood:  And I think with academics, you have a lot of the same problems of practitioners versus people in the ivory tower studying.  And so I think you gotta have a mixture of thinking and doing.  So as long as you have a good mixture of those two disciplines, I think you're gonna be fine.  I don't think the terminology--I get annoyed by the fact that people really harp on this terminology issue, and I think it's more about what you're doing, versus what you call it.

Spolsky:  In defense of the Canadians, it was pretty much the students in Canada who lobbied for a software engineering curriculum to be available.  And that was because they were directly complaining at the irrelevance of many things in computer science to being a software developer and the computer science department's inability to teach kids things like source code control, to teach them code hygiene, to teach them anything about working on a team of software developers.  The computer science curriculum as it developed just wound up being a different thing.  Y'know, it's like trigonometry versus civil engineering. At its heart, there are probably two or three classes that you both wanna take, but fundamentally, they really are different courses.  And more power to them.  It's sort of interesting that that was a student movement in Canada, that they were actually able to sort of persuade their universities to create this true engineering curriculum for software engineers which, I'll bet--I don't know the details, but I'll bet probably only has about a quarter of the courses in common with computer science.  

Atwood:  Yeah, and I love the message there, because it really is--I was appalled to read that a lot of computer science--or whatever you call it--degree students had no practical experience with source control.  And that is as fundamental as it gets to the practice of actually writing software.  And I felt like that was a huge oversight.  So it's a tremendous credit to the Canadian students that they forced this issue.

Spolsky:  That actually segues well into this call, I'm gonna play another call, from Nick:

[45:43]

Nick Malaguti: Hi, my name is Nick Malaguti, and I'm a computer science student at Stevens Institute of Technology.  I'm going to be a senior in the fall, and in order to graduate we are required to complete a team project.  I'm not a fan of doing real-world projects as an academic exercise for two reasons.  One, there is no real hierarchy within the team, because everyone involved is a student, and two, if the project cannot meet the hard deadline at the end of the semester, it is not possible to move the deadline and still complete the project.  Since you have both worked--

Spolsky:  That's real life.  Both of those are real life, I'm afraid to say.  In real life, software development teams often don't have anybody who's in charge, and they are teams of peers.  And also in real life, sometimes you have to ship, y'know, you have to ship at the end of the semester, whatever that may be.  If you're working in game development, for example, that's about as hard a deadline as you can get.  If you work for the IRS, when you have a coding deadline, it's extremely hard.  

Malaguti: --professionally in software development, what steps can I take as a project manager to mitigate these constraints and still complete the project successfully?  Also, if you can recommend a free project-management software solution, I would really appreciate it. Thank you!

Spolsky:  Woo, FogBugz, FogBugz! So, first of all, second of all, FogBugz is free for students: you go on to FogBugz, you make a free trial, and then send us an email and say, "Hey, I'm a student, could you please extend my free trial," and what we'll do is, we'll make that free trial last all semester for you, or all year, until your project is done.  That was the second question.  What can you do to mitigate this? I actually think that learning how to work on a team with no--a team of peers where there's nobody in charge is a really important skill, and a really important and valuable thing to learn.  

Atwood:  Absolutely, I think you answered it almost immediately straight away.  I think part of his question is wishful thinking that there's this idea that out in the "real world" you don't have to deal with these crazy people and these crazy problems, but I think you'll find that the academic world, in college is like as good as it gets.  I mean, it doesn't get better when you get out in the world, right?  So learn to deal with the problems there, because you're gonna have a lot of the same stuff.  And everything is, to a disturbing extent in the world, personality-driven.  So the more you can learn to deal with that, I think, the happier you will ultimately be.

Spolsky:  Being able to get things done--there's a book, not the best book in the world, but the title of the book is great, which is, "Getting Things Done When You're Not In Charge"--and this is one of the most fundamental skills that you can learn in life, getting things done when you're not in charge.  We have a management training program, a small management training program here at Fog Creek, where we train people that wanna be managers of software companies, and managers of technology, and it takes me a while to explain to them that the way they're going to learn to manage is not by being put in charge of a project, but rather by building their own reputation, and getting people to listen to them simply because they're right.  In other words, they have to learn how to get things done without being in charge, which will make it easy to get things done when they are in charge later.  

Atwood:  Yeah, it's a great question, let's do one more.

[48:36]

Spolsky: OK, another question.  I don't know if I have another question.

David Alison: Hi guys, my name is David Alison.  I live in Ashburn, Virginia.  I have, er, I'm really excited about this show, this sounds an interesting idea and I'm interested in seeing how it evolves.  The question I have for you is: as a .NET developer that does web based solutions, I'm curious how you guys look at things like the Google App Engine and the impact you think that's going to have, you know do you see that evolving on the .NET side where people will be able to at some point from within a solution or a tool like Visual Studio be able to deploy their application to a scalable hosted solution easily, and as I've been doing web based development for a long time and that is probably the single most difficult thing, is actually, er, it's not building the application, it's supporting it, it's scaling it on the back end, it's all of the IT and infrastructure you have, and that's something that the Google App Engine kind of makes all go away, or the promise of it is very straightforward.  So I'd love to have you guy talk about that and hear what both of you think on it.  Thanks.

Atwood: I can start a little bit on that one.  So I think what Google and lot a lot of other companies are doing now are simply removing what I call the software installation barrier, where everything just runs out of the box, there's no software to install, it's sort of like the browser model of do you install, you know, Facebook?  No you don't you just go to the Facebook website and everything just works.  So, with Google App Engine, you know, all your development would essentially be ready to go out of the box.  Like there's no ... Think about what I had to do with StackOverflow.  I had to install Visual Studio, I have to secure a dedicated server.  All these intermediate steps I have to to get my app go live on the web.  Whereas with something like Google App Engine, you go into your browser, you write some code, and then bam, it's consumable on the web almost immediately.  So they just removed a lot of the intermediate steps.  To me that's what I see it as.

Spolsky: Er, that's clearly the goal.  That's obviously what they're trying to do. We go a long ways to go there though.  The first issues are, if you're going to write code that can be automatically scaled, you have to write code with constraints.  For example if you like relational databases, you can just forget that, 'cause you don't get relational databases anymore.  A relational database doesn't scale beyond a single box, basically.  There are ways to do that, but you don't get the real linear scalability, so you've got to work with a very very different database model that is not nearly as flexible as what we're used to from relational databases.  Maybe it is.  Maybe it's better, who knows?  For all intents and purposes though, if you look at like Amazon DB, that stuff is all incredibly weak compared to what relational database programmers are used to being able to do.  So if you were writing a new project from scratch, you might want to develop it for one of these systems.  Right now, it seems a little bit scary and I haven't really gotten over this, which is: would you really build your mission critical business applications on ... you know at what point can you actually start trusting Amazon or Google or Microsoft now with their Mesh thing ... at what point would you really start trusting them to be there with the reliability that you need?  I mean I suppose they could probably  ... There's a bunch of different aspects to this.  One is I assume they could build something more reliable than you could in most cases, so that's good.  On the other hand, what if Google suddenly decides they don't want ... you know they want to charge more.  You're sort of stuck, you have to pay them, they're kind of the monopoly provider.  Or what if they decide they want to charge you by the byte and they used to be charging you by the kilowatt or something. 

Atwood:  Certainly there's an issue of scale.  If you're going to be really big or, have an independent entity you want your own server you can totally control.  You don't want those constraints by potentially one of your competitors, right, I mean that's certainly something to think about.  I know in terms of blogging, one of the things I first recommend to people is get your own domain name.  Do not let your name be owned by blogspot or blogger or whatever

Spolsky: Yeah, cause you're going to regret it.

Atwood: You're going to regret it, you going to have no flexibility. You can't move.  All that stuff.  So I think that's a concern as well.  But I do admire what they're doing in terms of removing the barriers to getting things done as a programmer and just putting stuff up on the web.  I definitely admire that and I think being not tied to the executable view of the world like Microsoft is, and the desktop view, is really a strength for them in terms of getting more stuff out there.  I don't know what the quality will be but I think it's certainly valid and something Microsoft-

Spolsky: I mean we might, and I hate to be an architecture astronaut here, cause this is all architecture astronaut-ure.  This is architecture astronomy of the first degree.  That said, I kind of feel like these development environments built ... Right now if you develop on Google your code is not portable to Amazon web services which anyway provides a different set of services than Google provides.  It's not really portable to anywhere.  You develop on Amazon Web Services, it's not portable to the Microsoft stack.  You only have one provider, they're all providing a very very different set of services.  Many of them are trying to provide the same thing in kind of non-overlapping ways.  And this is very much like the platform wars of the olden days.  And until there's something reasonably standard that you can get multiple providers for or that everybody's using anyway, it's kind of like a lot of people won't place their bets until they see who's going to win.  Because there is this terrible risk that Google will suddenly realize that they just can't win in that business, there's no way to make money in that business and they just shut it all down and they tell everybody you've got three months to get your stuff off 'cause we're turning it off and if you've built a business of that then you're in trouble - to put it lightly.  So right now I think a lot of the more conservative businesses and a lot of the more careful businesses will be saying , "I don't need another dependency, yet another way my business can be ruined. I'm going to build something that I control or I'll wait and see who wins here". Sort of like the Blu-ray vs HD-DVD wars.  People won't jump in until it's clear that there's going to be a winner. So there's going to be a lot of thrashing this out as these is very, very 1.0 if not 0.0 versions of these services come out and they're a lot of fun to play with and you know, when version 4.0 comes out and it becomes clear what the technology choices that most people are making, and it becomes clear that there's a sustainable business there for the platform vendor so the platform vendor's not going to go away then I think only at that point will you see the masses actually converting to this model of development.

[56:01]

Atwood: But Joel, do you see this as a winner-takes-all type of scenario, I mean, this is the new world of infinite bytes, there's not these plastic disks that have to be distributed and carried at BestBuy, do you really see it as this old-world winner-takes-all?

Spolsky: No, I don't think it has to be a winner-take-all scenario, no.  Not necessarily.  On the other hand, the truth is a lot of the companies getting into this business, I guess there's not so many - Amazon and Google are the most prominent - and I guess there are a lot people that provide things like, there always places you can get a virtual machine.  Even a virtual server that you get from Amazon where you basically configure it yourself, is something that's generic enough that you can imagine getting that from someone else.  In the case of Google they're really giving you a special and unique programming environment that it would be very very hard for anyone else to reproduce, so if you've created a crap-load of code for Google you're not going to be able to move it to somewhere else with any reasonable [indistinct]

Atwood: Right.  Don't people say the same thing about Microsoft, though?  That, like, you're part of the Microsoft ecosystem so you're totally locked in?

Spolsky: It depends on how you've selected your Microsoft [sic] and that can definitely happen.  On the other hand, if you write .NET tools you've got Mono at least.  You know, there's another implementation.  You're writing Windows code not because you have the ability to port it easily to somewhere else, you're writing Windows code because that's where your users are.  You need to run on Windows because that's what people have, you just don't have any choice in that matter, and people do have it.  So maybe it's not winner-takes-all in the sense that there's certainly a healthy ecosystem for Apache and IIS, there's lots and lots of different webhosting technologies, there's no reason you can't pick one, on the other hand there is sort of the risk that these vendors will lose interest.

[58:10]

Atwood: No, it's certainly a very interesting development.

Spolsky: I have to say, from experience, it's years and years away, and there's definitely going to be, in two weeks you're going to see 37 dumb little twinkie little startups that do something like order Twinkies over the Internet, showing up on TechCrunch all of which were built with Amazon webservices, and the minute you see them getting listed on TechCrunch you'll go there and you'll see whatever Google's error message is for an application that uses too much bandwidth or too much CPU power and that's all you'll really ever see of these services and that will be the end of that.  That'll be this first euphoric wave in which dumb things are built and they never go anywhere.  But I really do strongly believe that whatever the core services that you're building, you've got to build it on tools that you either control or that are available from multiple sources or that you totally trust.

[59:07]

Atwood: Right.  I love, I know you had a classic post about Excel, and how they had this really radical dependency-rejection culture.  I think that's important to cultivate, you have to choose you dependencies very very wisely, you're going to have them, everything's a dependency, you have a CPU that you run on, and all that stuff.  It's something you really want to think about and give due diligence to, but-

Spolsky: "find the dependencies and eliminate them" was their motto.

Atwood: Where you can.

Spolsky: I don't remember them saying "where you can", I think they said "find the dependencies and eliminate them" - that was pretty much the end of their motto.

Atwood: We're not as hard-core as the Excel.

Spolsky: You know, if they really believed in it, they'd be selling you an Excel box that you bought in a box from a Microsoft store.

Atwood: I think actually they'd be running in a virtual machine, which I don't think is actually that far off in the future.  But I think - I have this radical theory - that everything will be delivered in a virtual machine eventually.

Spolsky: That'd be really nice.  That's not a bad idea, and definitely you'll see FogBugz moving not quite to a virtual machine, but we're going to package a lot more of our stuff on Unix we're probably going to start chipping our own version of Apache just to run it on a different port.

[1:00:20]

Atwood: Oh sweet! You guys are gonna have...

Spolsky: Uh huh.

Atwood: ...the FogBugz distro?  When someone installs...

Spolsky: Something like that.  I'm not really sure.  I, I shouldn't talk about this until it's designed, actually.  But, y'know, we are trying to, actually, at least have a distribution that, that includes more parts of the stack so that out of the box, if you don't mind just throwing our stuff on there uh, you'll get something that has been tested together and works and if you really need to use the Apache that's on your system, then... ok, but, but, but if you don't, then you don't.

Uh, okay, so before leave I just wanna um, uh, uh, er, once again encourage our uh, listeners, if you have any questions, comments, uh, or anything you want us to play on next week's podcast, to uh, make a little MP3 recording or Ogg Vorbis um, and email that too...

Atwood: Podcast@stackoverflow.com.

Spolsky: ...podcast@stackoverflow.com.  Uh, if you don't know how to record an mp3, let me just play this...

Tim Patterson: Hi, Joel and Jeff.  This is Tim in Austin, and I heard you guys talkin' about how people might record their audio uh, to send you questions and that.  And I found a thing from Dave Weiner's site called blogtalkradio.com.  And, basically, if you go there, it's got a phone number; you can call in, like I did just now, uh, record whatever you want, hang up the phone, and then it uh, outputs your recordings in a simple RSS feed.  It's got a little link -- on the page -- to an mp3 of your audio which I'm about to send you...

Spolsky: It's real easy.  Blogtalkradio.com: you call a phone number and then it puts up that mp3 recording at a url that is the phone number you called from.  So, basically it's an extremely easy way to make podcasts.  If you wanted to make your own podcast you could just basically call that number every time from the same number... and that phone number -- your phone number -- would be your podcast's url.

Check it out.  Very easy: blogtalkradio.com or just use the microphone on your computer, record an mp3 uh, and uh, send it us.  Um, stereo is not necessary.  Maximum time: 90 seconds... um, even less 'cause y'know I gotta go through a lot of them and figure out what to play.  Thank you very much, and we'll see you next week!

Atwood:   See you next week.

Joel Spolsky and Jeff Atwood chat about StackOverflow.com in their third podcast.

Spolsky:    Hello!

Spolsky: Oh wait, I just got a picture of... who's that?

Atwood: It's Ogre from the movie Revenge of the Nerds.

Spolsky: Is that that guy who was in A Weekend at Bernie's?

Atwood: He's possible, he's a character actor.  But that specific movie is Revenge of the Nerds, where he screams "Nerds!"

Spolsky: Got it.  Everybody's favorite movie.  Alright, so we're coming to you today on the StackOverflow Podcast #3.  Hopefully better sound.  We're recording this using Skype Fand Pamela for Skype, which is a little $20 program that you buy and you add it into Skype and it lets you record those conversations and should allow us to play sounds and you know what? I got rid of all that audio equipment that I had here on my desk.  All those mixers and stuff that Leo Laporte and Adam Curry convinced me were necessary.  I don't think they're really necessary.  I think we're just going to record this using software and then I'll use a program called Levelator, which will basically adjust the levels on the file that we generate so that we all come out at the same volume.

Atwood: Yes, there was growing amount of unrest about the difference in volume levels.  I think people were perceiving it as a slight, which ended up having difficulty in hearing me.

Spolsky: And I don't quite know how much Levelator will really work, because sometimes one person has a lower voice or a more bass-y voice, it might sound like they're at different levels even though they're not technically at different levels.

Atwood: Right.  And Joel, what kind of headset are you using?  Anything fancy?

Spolsky: No, I just have a plain old Plantronics headset - not the USB thing.  The advantage of that is that then I can plug them into this little switch to switch between the speaker and the headset.  Basically, when I'm not talking on the headset, you want the sound to go out the speaker, otherwise, you don't hear it when your computer rings.

Atwood: Yeah, I'm using Plantronics, but I'm using their USB model, so it shows up as another sound card.  But what I like about that is that you can configure applications so that they specifically talk to the headset, like Skype for example.  So you get this nice segregations of sounds between outputs.  It's pretty cool.

Spolsky: That makes sense.

Atwood: It's also very very clean, cause Windows detects it and it automatically works and it's really pretty nice.  So I do recommend USB headsets as a general rule.  Easier to deal with.

Spolsky: That'll be the next iteration of this.  We should probably not make this a podcast about podcasting I think.  Probably the first three episodes of every podcast in the world are about podcasts.

Atwood: Yeah, well I think we're just trying to iteratively improve what we're doing.  We just want to make sure people know that A) we're listening to their feedback and B) acting on it.  That's all.

Spolsky: That's right.  So what's new?

Atwood: So let's see.  Some new things.  I had a few things left over from last week that I wanted to talk about, we didn't get to.  One of them, and these are largely based on the feedback that we got off the initial post that you and I both did on StackOverflow.  One of them, I kinda covered on my blog, was the "Are books dead?" theme.  A lot of people got that out of your post, your initial post.  Cause you started very provocatively with saying software developers don't read books any more, which is largely true, but there are some caveats around that.  And when we talked about doing StackOverflow, we believe it's going to be complimentary to what I call classic programming books, books that teach you how you should program and why you should program.  The theory of programming rather than "Here's how you do this in Ruby." or "Here's how you do this in Java."  Now those kind of books I love, and we feel that StackOverflow fills a niche that those books don't fill, which is namely the immediate gratification that we expect of programming:  You have a problem and you want an answer to that problem.  And that's what StackOverflow is really about.  And actually, you know Joel, it's funny, when I started my blog, I literally founded it on the idea of these classic programming books that I wanted to read and share with people cause I didn't have an outlet for that in my current place of employment at the time.  And I never found your - you had a recommended reading list and yours and mine are really similar.  There's a lot of overlap.

Spolsky: There were two reading lists.  One was a really really long time ago.

Atwood: 2002.

Spolsky: Yeah, God, I think the original version of that might have been 2000.  That might have been something that I did really early on.  Just because I was getting so many questions saying "Well, what should I read next?"  I don't even know what to say any more.

Atwood: You just point to your blog post.  I had an e-mail conversation with, and I'm probably going to mispronounce his name, is it Steve Yeikky?

Spolsky: Yeggy.  His friends call him Stevey.

Atwood: But I had an e-mail conversation with him cause, do you remember, Joel?  I remember.  It's weird how you'll write stuff and I'll focus on little phrases that you've written.  And one of those phrases that I've always focused on, you were sort of a relatively early adopter of the Mac and one of the observations you made is that you found the font rendering really screwy.  And I thought that was interesting and I never really understood what it was about, until I downloaded Safari.  And Safari, on Windows, is unique in that it thrusts you into the world of Apple's font rendering.  Like they literally ported over Apple's font rendering lock, stock, and barrel.  So I was looking at the font rendering going "What happened here?" You know?  And I went back to your post and then I wrote a post about it and I wasn't necessarily saying it sucked or anything, but I wanted to understand why they made that choice.  And it was good because I learned so much from that and you actually had a follow-up post about explaining "Do you favor the font designer like Apple does or do you favor the pixel grid like Microsoft does?"  Not that one is more right than the other, it's just understanding the choices you make, which is true in so many things in programming, right?  It's not like there's the One Right Choice.  It's understanding all the trade-offs involved in your choice and making the appropriate one.  And Steve Yeggy just discovered that.  I don't know if you saw his post, but he's like "I was in an Apple store and I saw how great the font rendering was and I can actually can read it from a distance and I decided that Apple just renders fonts better." And so I e-mailed him, basically, links to my blog post and I felt kind of guilty saying "hey Steve, I don't really want to talk to you I just want you to read my blog."  But I felt that it was really helpful so that he could get a sense of why he had that perception and what's going on there.

Spolsky: Yeah eventually people figure it out.  I honestly don't even think that the people working on typography at Microsoft or Apple are even completely necessarily aware of what they are favoring and why their font rendering is so different.  And for any listeners who are listening who didn't follow the whole discussion, Microsoft had this ClearType group that actually specifically designed some fonts that were designed for screen legibility.  And that meant that the font itself was designed to fit in the pixel grid and Apple has never done that.  They've always taken print fonts and they've used anti aliasing to just kind of approximate and it just doesn't quite fit in the pixel grid so well.  And so it does come out blurrier but it is truer to the underlying font.  Certainly if you are doing design work for the printed page there's a huge difference between these fonts on the printed page where you have 300 or 600 or 1200 DPI that you don't get on the computer screen where you have at best 96 DPI.  The truth is - for computer monitors - there are really only four or five possible fonts that you can see the difference between unless you really do this Apple style anti aliasing.  At smaller fonts at like around the 9pt, 10pt size on Windows all the sans serif fonts look like all the other sans serif fonts and all the serif fonts look the same and you can barely tell the difference.  And the difference is that Apple's way of rendering those you can sort of see the difference in the general weight, the feel of the paragraph of text, does it feel crowded or spindly, does it feel heavy or light, and how dark is a whole paragraph of text.  That's something that Microsoft's fonts never preserved because they've all been hammered into the on screen 96 DPI or 72 DPI pixels.  The other difference is sort of a long time difference which is that traditionally Apple did have 72 dots per inch and Windows had 96.  So pretty much Apple had to use forms of anti aliasing to show you anything.  They truly had blurrier fonts for a long time.

Atwood: Yeah and the other thing I liked in your response to that was that you pointed out that people, and you see this too in programming languages as well, people like what they are used to, right?  There's certainly an aspect of I grew up with this or this is how I learned to do it or this is what I've always seen so this is what I like.  And I think that is why as a Windows user being used to ClearType, which I think ClearType is excellent, seeing Safari's rendering I was like "Oh my God, my eyes are going to bleed from the weirdness of this font".  I think that if you saw it everyday on the Mac side you would grow used to it and say ok this is the way a font should look and I've heard people describe ClearType as quote "spindly."  Because it is hammered into the pixel grid so it doesn't blur over it is very rigid, it's very tight, aligns very sharply with the pixel matrix.

Spolsky:     Yeah, when you have a line of text, imagine a horizontal line that's a part of some letter, it's either gotta be one pixel wide or two pixels wide, and those are you're two choices.  Whereas on the Mac, it could be a pixel, and then the pixel to the right of it could be a little bit grey, to imply that it's a little bit wider.  And obviously the sub-pixel rendering as well, where they're turning on and off the individual red, green, and blue sub-pixels--so every pixel has got a red, a green, and a blue element that can be turned on and off independently.  So anyway, yeah, I think it really is sort of a little bit subjective, it's a little bit what you're used to, and it's just wrong to try to use--or, you're almost guaranteed to not be well received if you use Apple rendering on Windows or Windows rendering on Apple.  It's just gonna make you look foreign, strange, and badly ported.  And, I believe somebody told me it may be possible in Safari--I haven't tried--to turn off the Quartz rendering and use the native rendering for your fonts.  Not a hundred percent sure if that's possible, but if I were Apple, that would be the default, because there's no reason to have people just not liking your web browser just because it appears arbitrarily different.

Atwood:   So one of the cool things about--I think Safari's actually a fantastic browser, I have a very deep respect for what the WebKit team is doing.  I think they're really innovating in ways that Firefox isn't, and certainly IE isn't.  But I agree that they should back-port that, and in fact they have.  They announced their latest, on what they call "nightlies".  You can actually switch to the Windows native method of font rendering, which I thought was very nice.

Spolsky:     Cool, yeah.  And that should just be the default, 'cause they're just gonna get yelled at on Windows, even if they're right.  It doesn't matter, it's just sort of like, y'know, walking into a restaurant in Rome and shouting loudly in English.  You're just gonna aggravate people.  "Speak Latin, dammit, this is Rome!"

[12:01]

Atwood:   Yeah, but you know, font rendering is neat, because it's very computer sciencey.  Like certainly Knuth spent all those years working on his, y'know, TeX, LaTeX, or TeX layout engine, where he was gonna, "Oh, I'm gonna write a programming book," and then he got distracted for like five to seven years,

Spolsky:     I thought it was, like, fifteen or something.

Atwood:   All these technical issues in computer science on how to lay out the printed page.  It's really, really fascinating.  And is there anything more fundamental than font readability?  It's really, really fundamental to readability.  And what do you do online, all day?  At least when I'm doing this, the time is just read, read, read.  So I think these are really important issues, and it's really fun to understand them.  I think it's very helpful.  I think it's very germane to programming.  Because sometimes people will criticize my blog and say, "What does this have to do with programming?"  And I would say, if you think about it, this has everything to do with programming.  I don't view programming as the act of typing in code and compiling.  It's so much more than that, and I think this is a good example of that, and I found it fascinating.

Spolsky:     Cool.  OK, so fonts.  Do we have any to-do's on the to-do list to cross off there? Any agenda items? No? What's next?

Atwood:   No, no.  We do have a server now, a dedicated server.  I want to talk a little bit about the technology stack we're going to use.  Now this ties back to another theme I saw in the Reddit comments to your post and my post.  We are going to be language agnostic in terms of the actual site itself.  This is not a Windows developer site, necessarily.  We're gonna really encourage an open kimono policy of, if you're programming, and you have a question, or answers, then that's what StackOverflow is about.  We're not going to segregate, "This is the BASIC programmers' ghetto," right? Or, "This is the really cool guys who know C."  And by the way, I've gotten so much crap about the fact that I don't know C now, thanks to you and your curiosity.

Spolsky:     [laughs]

Atwood:   So I hope that makes you happy, I get a lot of crap about that now.  I don't know pointers--

[14:02]

Spolsky:     Are you gonna learn C now?

Atwood:   Yeah--well, no I, I dunno.

Spolsky:     C'mon!

Atwood:   To me it's like, should I go spear-hunting--

Spolsky:     All the cool kids do it!

Atwood:   I just feel like I'm gonna be spear-hunting for my own food now, instead of going to the grocery store, by worrying about this pointer--

Spolsky:     Well, let me ask you this: should you ever do something that's not the most practical way to do something?

Atwood:   Well sure, I mean, that's not a real question, is it?

Spolsky:    Well, yeah, because your argument was, "It's not practical to use C, so should I do that? No."  And I'm just saying, well that's not a valid argument.  It's not actually the case that, just because C is not practical--Although, y'know, we got some pushback from that.  There's millions of systems, yes, I know, the Linux kernel is written in C, there's lots of existing legacy code that's written in C, and there's future code that is, and will, and should be written in C.  And I sorta made an off-hand comment in one sentence, which is that C is almost never the right choice for a language for a new coding project. But y'know, we were talking about the millions of types of code that somebody sits down to write in the world, and only a small percentage of those is C the right choice.  But that class still exists for which C is the right choice.  But that's it, I mean, you know it's true you could say "I want to be very pragmatic, I'm never gonna have any use for this, why should I learn this? Or why should I do it the hard way once?" But I think what all of those of us who are giving you grief are trying to tell you is that the process of doing that, whether or not you like it, you're gonna learn some fundamental things that--Y'know, we see C as being--it's not quite like teaching Latin, in which the effort--y'know Latin is taught in the high-schools in order to teach you to be logical and rigorous, and in order to think about things that are difficult in a particularly logical pattern, teach you a way of thinking.  And I don't think that's exactly true of C.  I think it's more true just that it's a language that basically, it sort of reveals directly certain underlying and important concepts of computer programming, that are kind of crucial.  It's sort of like the difference between an automatic and a manual transmission in a car, that it's true you can always find an automatic transmission, and I wouldn't tell you to go learn how to drive a manual in case one day you're caught and the only car available is the WWII era Jeep, and you need to drive around in that, so you wish you had learned how to drive a manual transmission.  But what I'm really telling you is, learn how to drive with a manual transmission so you understand gears, and you understand gearing ratios, and you understand low and high gears, and you understand that fundamental relationship between torque and speed.  I don't wanna beat this C/C++ issue into the ground.  But, the server, you were talking about, we have a new server, that's what we were talking about.

[16:57]

Atwood:  Yep, yep, so we have a dedicated dual quad-core Windows Server 2008 64-bit server from CrystalTech, and that's all good to go.

Spolsky:  [joking] How could you possibly use Windows, good Lord, man!

Atwood:  Well, that's what I was gonna jump into. So, one of the reasons I'm using Windows, even though StackOverflow the site will be absolutely language agnostic, and decidedly so--that's one of our stated goals, is to be agnostic about language--we are not personally going to be--

Spolsky:  Except Lisp.

Atwood:  [laughs]

Spolsky:  Lisp users are not welcome, under any circumstances.  But apart from that, we're going to be completely language agnostic. [laughs]

Atwood:  We are not personally going to be language agnostic, because we need to actually build the site.  And in terms of people actually working on it, Joel's in an advisory role, I'm gonna be writing code, and then a friend of mine, Jarrod, I'll be working very closely with.  So it's sort of like 1.5 developers, so I need to actually get things done.  In order to do that, I'm gonna fall back on what I know, and what I know is essentially ASP.NET.  So ASP.NET is gonna be the platform.  And I actually really like ASP.NET.  There's things I don't like about the stack, like the webforms model, and so on and so forth, but as a core programming environment, I feel like it's more than up to the task, quite a bit of tooling around it that's gonna help us out.  So I'm looking forward to that.  I just want to get that out of the way early on as far as like technology choices.  And also to segregate and say again, what we build the site in does not equate to what the ultimate StackOverflow site will be about, in the end.  Technology choice doesn't matter.  And Joel, you know that more than anybody else, with the whole Wasabi thing, right? Like--which I've come full circle on, I used to be very critical of that--and now I've decided, it doesn't matter.  Because unless you're open-source, nobody's gonna actually see your--

Spolsky:   Ahh, it does matter, you see, because Fogbugz was written in Wasabi, and therefore we were able to port it to .NET in, y'know, about a month of work.  And so Fogbugz, as of today, is actually running on .NET, which means it runs on Mono, it's a lot faster than the old VBScript/PHP version.  So, having control of our compiler has actually really paid off.  And we've got some features in Wasabi that aren't in C#, that aren't in any other kinda off-the-shelf language we can use, it's really nice.

Atwood:   No, I mean, to me it's like, I don't care if you guys are using black magic at this point.  As an external consumer--I mean, if I was working at Fog Creek, I think I would have more deeper concern about what we were programming in--but as a consumer, who cares, right?

Spolsky:   Right, that's true, they shouldn't--they don't--y'know I've seen a competitor of ours who will remain nameless, actually advertising that their product is built in Java, as if this was a reason to buy it or not buy it.  And I don't think anybody buying software really cares, except for a very few, shall we say, teenagers, who are still kind of in their throes of religious fundamentalism, or flag-waving-ism, or whatever it may be.  And they've decided that you're part of the enemy camp, and therefore they don't want to use your product, because you're the enemy, because you're insufficiently hateful towards Java or Microsoft or PHP or Lisp, or whatever the case may be.

Atwood:   Yeah, and one final thing before we get into the listener questions.  I think that covers the logistic side, so I want to cover first, and somebody made a comment asking if I had "jumped the shark by osmosis" now that I'm working with you, which I thought was very funny, and also referencing that original post I made about the Wasabi thing, where--

Spolsky:   OK, so what is, exactly, "jumping the shark"?

Atwood:   So, jumping the shark is based on a Happy Days television show.  The Fonz--remember that character, "hey, the Fonz," on Happy Days?

Spolsky:   Yeah, sure.

Atwood:   So, in the later days of Happy Days, when it was sort of--the show was falling apart, not being as popular--first they added a little kid.  That's a thing, a lotta times shows will do that to sort of bolster the ratings, y'know, "Oh, look, we added a cute little kid--"

Spolsky:   Is that Chachi?

Atwood:   No, I think the classic example is Family Ties, that Michael J. Fox show, they added a little kid to that show at the end of its life.

Spolsky:   Isn't that Leonardo DiCaprio?

Atwood:   Gosh, I don't even remember.

Spolsky:   That was Leonardo DiCaprio!

Atwood:   Yeah, so that's one of the go-to devices.  And the general term for a show that's falling apart, not popular anymore, at the end of it's lifecycle, but desperately wanting your attention, is "jumping the shark."  They'll do something just ridiculous to get your attention.  And in this case, in Happy Days, it was the Fonz jumping a pool containing a shark on his motorcycle.  And he was actually wearing shorts, too, which--the Fonz wearing shorts just doesn't compute.  Would the Fonz ever really wear shorts?

Spolsky:   No, I think he had to wear jeans at all times.  It was a law.

Atwood:   Exactly, exactly.  So yeah, that's what the "jumping the shark" reference is about.  E.g. your popularity had flagged, so you're trying to get attention, et cetera, et cetera.  That's what that was about.

Spolsky:   Oh, I see.  "Tonight, on a very special Joel on Software," in which I become addicted to something and recover from it, all one 22-minute episode, 30 minutes with commercials.

Atwood:   Right, no, I feel a little awkward about that.  It's a lot easier to criticize someone over the web, than it is directly to their face, by the way.

Spolsky:   Yeah. [laughs]

Atwood:   But, y'know, at the time I really was kind of upset about this, because people misunderstand, and they think, oh, you're just doing this to get ratings, and let me--that is absolutely not true, like the thing I did with Paul Graham, the thing I did with you, I was really, on some level, really offended by that information, it really bothered me.

Spolsky:   I think a lot of people were offended that we did Wasabi.  And I think personally, the reason I believe--I mean, you can tell me if it's different in your case--but personally the reason I believe that is I don't think the average working programmer--and by average I mean, y'know, the majority of programmers, understands how easy it is to build a compiler.  And that that is--because, pretty much anybody who has done a computer science degree has taken a course in compilers, and knows how to sit down and write a compiler.  Or maybe it's only the good computer science degrees? I have no idea.  Seems to me like that's sort of one of these things that you kind of learn to do, just like, if you're gonna be a chef, you learn how to make a risotto.  It's not that hard.  And a lot of working programmers that are working, shall we say, higher up on the stack, where they're building applications and software using these great and exciting tools that somebody else gave them.  And for them, building their own tools just never really entered into their imagination of the realm of possibility.  So I think that if I had said, y'know, we build our own desktop computers, we buy the boxes and motherboards, and we snap it together ourselves--which we don't--but if I'd said that we did, would anybody be as offended? Y'know, maybe not, they'd be like, yeah, I can see how you would do that, it's not that stupid.  But a compiler, to many people, I think a compiler is such a dark mystery as to how that thing could possibly work, and what it could possibly do, and why would you ever make your own? So I think a lot of people were a little bit shocked by that.  A lot of people also--y'know, I don't always phrase things as well, and then I actually introduced Wasabi in a two-part answer to a question that a friend of mine asked me.  And a friend of mine asked me what application he should be doing development in, what programming stack, basically, .NET, Java, PHP, whatever the choices were, and it was sort of a major new project, and it was very mission critical for them, and I do have to say that it was sort of, in some sense, enterprisey.  Whether that's a good thing or not.  In other words, it was not the kind of thing where they wanted to give people, y'know, do the latest and sexiest thing.  They really just needed to get their work done, and they needed it to work, and they needed it to be reliable, and they couldn't be messing around with a stack that didn't have--they didn't want to be tweaking their stack all day long, or messing around with their tools.  They just wanted reliable tools that did what they needed.  And he sort of said, y'know, what should I use, and then he said, what do you use?  And I answered both questions in sequence, y'know I said, it doesn't matter: if you use the Java stack, that's fine; if you use the ASP.NET and the Windows stack, that's fine; if you use--I don't even know if I said anything about PHP.  I think I said Python is just about ready for prime-time, which I still feel, and Ruby is not quite ready for prime-time, which I still feel.  I think that Ruby is--y'know I'm gonna be speaking at the RailsConf--so Ruby is wonderful, you guys, it's just great, it's totally ready for prime-time.

Atwood:   [laughs]

Spolsky:   No, but honestly, there are people that are running into deployment issues with Ruby.  I think that Twitter is not as stable as it should be, and I attribute some of that to Ruby.  I've seen some failed projects, and some projects that have succeeded, and that will not always be the case.  And Ruby has enormous strengths, and enormous advantages--it's also got some disadvantages, like in terms of performance, that have not yet been fully solved.  And I don't see any reason why they won't be, but they haven't yet.  The difficulty of deployment, that kind of thing.  I'm not such an expert on it, I'm not a deep Ruby programmer.  I know Ruby, but I'm not an expert on it by any means, I've never written any major applications in it.  But I can tell you just from just listening to the people that I work with and my customers who use Fogbugz, and the people that I talk to all day long by e-mail or on my website, that there are just too many cases of Ruby being not quite ready for prime-time.  Which doesn't mean--it just means for his application, it wasn't there.  So, I'm being too defensive there, but basically--and also, don't forget this was when Ruby on Rails was less than a year old, I think.  And then I answered his second question, which was "what do you use?" and I said, well we use Wasabi, it's a custom thing.  And then some people saw that and said, "Oh my God! You're saying that Ruby's not ready, and you're using some wacky--"  Y'know our situation is very different.  We are the kind of people that love to tinker with our stack, we like to make our own tools.  Every single programmer at Fog Creek is smart enough to write a compiler in a week.  So for them to just edit the compiler and change the compiler is easy.  If the compiler doesn't work the way we expect it too, we fix it.  We don't really care.  So for us, actually, using a crazy language like Wasabi that nobody else is using--as long as it gives us access to the .NET libraries, which it does now, and as long as we control every aspect of the compiler--that's actually safer for us than using Ruby, where if anything happened, we'd be at the mercy of somebody else's compiler.  I mean, I guess we could fork it and try to fix their bugs, but I'd rather have the complete control over all aspects of the technology that I use.  So some people thought that that was hypocritical, for me to be dissing Ruby on the one hand, and yet advocating the use of an even more ridiculous language, which isn't even published.  I mean, you can't even get it.

[27:55]

Atwood:  Right.  But I think, to me, it boils down to, you guys have a business, it's essentially closed-source.  As long as the product works, and people are happy with it, I don't care if you guys are using COBOL.  So that's the realization that I had.  This is an entirely internal thing for you guys, and exposing it doesn't ultimately matter.  And I think that's great.  What I was concerned about, though, was the idea that--if you've worked with developers at all, you've worked with developers that love reinventing the wheel for no good reason.  This is a very, very common failure pattern.  So my concern was, they would read "Well, Joel Spolsky says that we should be writing our own language." And they would go off and write hundreds and thousands of the crappiest languages you could possibly imagine.  Despite what you said earlier, I think it does take quite a bit of skill to do these things well.  Like, if you compare PHP, the language, with C#, the language, you can see there are some problems with this model, right? 

Spolsky:  Yeah, yeah.

Atwood:   Like one has a master language designer behind it, the other has thousands of just random people, and you can really tell.  So that was my other concern: people would read that and go "Oh, I'm gonna create my own framework, create my own everything," and it's all gonna be crappier than stuff you could just go out and get, that would work so much better.  That was my concern.

Spolsky:  That's true. 

Atwood:  So, y'know, it works on, I think, several different levels.

Spolsky:  That is true, and in fact, honestly, if we'd been starting from scratch, Wasabi would never have been the strategy.  The other thing that's very unusual about the Fog Creek case is that we had an existing body of code, of legacy code, basically, that was a large body of well-debugged, wonderful code that I didn't want to give up on, that had taken years and years to develop, that we needed to continue working, and we didn't want to have to rewrite all that.  So if it's a choice of rewriting, let's call it 20 developer years worth of code in a new language, versus spending a couple of months and writing a compiler that can interpret that old code, and maybe add some features.  So what we actually had was this old VBScript code, and that goes back to a time when Fogbugz was developed, and there weren't great alternatives.  Y'know, it was years before .NET, years before Rails, years before--I mean, it was long time ago, when VBScript was actually not a bad choice.  Even before PHP.  And we always had the criteria of--because we have to run on our customers' servers, we want to have sort of, the minimum runtime requirements.  We don't want to tell them, "and then you have to install this piece of this other stack."  In particular, we didn't want to have to tell them to get a Java Virtual Machine up and running, because that's not easy, and they're not really a hundred percent compatible.  We just wanted to be able to throw it on IIS or throw it on Apache, and have it run.

Atwood:  Right.  And again, I think the relationship between you and your customers.  If you guys are happy, and your customers are happy, it literally does not matter what I think.  And I think that is the iron-clad important message to get out of that.  It's your business, as long as everybody's happy, then why not?

Spolsky:  Well, on the other hand, it's not fair to say all blog articles which in any way try to second-guess what anybody is doing in any company are inherently invalid because it's between them and their customers.  You're certainly welcome to try and second-guess what a company is doing.  On the other hand, it is also true that people who criticize decisions that Fog Creek takes based on a couple of blog posts should realize before they criticize that those blog posts are mere snapshots as to what is going on here internally, and that, if there's a debate that happens at Fog Creek about how to do something, or what technology to use--y'know, in the case of some of the decisions that we made about the future directions of Wasabi, that was a two-day offsite with nine people where we went out to the Hamptons and we made marshmallows and hot chocolate and spent two whole days discussing how we wanted to do--how we wanted our technology platform to evolve.  And if you had been there, and you come to a different conclusion, that's one thing.  But to then just sort of read a blog post about it, or just to hear what I just mentioned about the two days, and immediately go off and write an angry blog post about the crazy people at Fogbugz/Fog Creek, and they don't know what they're doing, and so on and so forth.  Well, you have to recognize that you're probably missing some of the information that we had when we made that decision.  We're not necessarily stupid--although it's possible that we're stupid.  And it's just as likely that the outsiders are just a little bit misinformed.

Atwood:  Well, I think sometimes that's why people don't publicize a lot of the internal things that they're doing, for that reason, because of the misinterpretation and the lack of context.  So, one final thing before we get--I do want to get to some questions--we do have a logo design contest that ends, I think, today.  And I want to thank Paul Annesley of 99designs for sorta hooking me up and getting me sorta into that community.  But I've been really pleased with a lot of the logo submissions.

[32:47]

Spolsky:  Yeah, those are some pretty awesome logo submissions.  I don't know--I mean, you and I probably bring a lot of publicity to those contests.  Although--you, because I don't think I mentioned it. The amount of publicity that it has brought to those contests is probably relatively high.  Now I have a question--when you pick one, is that it?  You gotta pay the $512, and that's the logo that you get?

Atwood:  Yeah, as far as I know.

Spolsky:  The way it works with some the commercial ones, like LogoWorks, you get five different designers, or however many, depending on the package you choose, and they design the initial version, but then you can just sort of ask them to tweak it again and again and again, and you can just sort of modify it into something different.  Or you can tell them "I want this part of this, and this part of that," and you can basically go over several other iterations, like, "I love this design, but I think the colors need to be a little brighter, or the colors need to be a little darker, or get rid of this drop-shadow, or use a different font".  So 99designs doesn't have any kind of concept like that?

Atwood:  It's a pretty loose relationship, but I'm gonna be sucking up tremendously to the winning designer, because I really want to have a little bit of an ongoing relationship, for little tweaks like that.  So we'll see what happens with that.  One of the complaints I read through Twitter--I posted on Twitter that I was doing this--and I think some people were kind of offended, designers were offended by this process, they felt like it cheapened the craft, because there were all these people submitting designs that weren't necessarily getting paid, and so on and so forth.

Spolsky:  Yeah, it's sort of a winner-take-all.  The truth is, I'm very sympathetic to that, because these contests are sort of winner-take-all systems, where one person out of a hundred gets paid, and 99 people do work and don't get paid.  And I suspect what may be happening is that the designers who participate in these logo contests have their set of five logos that they designed, and they're just going to keep throwing them up for every single contest that seems even remotely relevant, with a little tweak here or there, and just hope to eventually hit one.

Atwood:  I agree with that, and one thing that's kind of cool is that Leon Bambrick of TimeSnapper--which a really cool sort of record-what-you're doing Windows time-tracking software.  It literally takes screenshots, builds a timeline, and a tag-cloud of what you've been doing--offered up some licenses.  So for the second, third, and fourth designs, I'm gonna be giving them TimeSnapper licenses, courtesy of Leon, who--it's very kind of him to do that.  So I'm gonna reach out to the people who didn't quite win, and give them something, which I think is nice.

Spolsky:  Yeah, I think also, the way the world works with graphic designers, there's sort of a real tendency--once you've been a graphic designer for a while, you've probably had some client that tried to get free work out of you by asking you to submit a design, or to do some work, basically, for free, and then, if we like that, we might hire you back.  And there's a lot of cheap and evil clients that will do this just to try to get free work out of people.  And so there's sort of an understanding around graphics professionals, graphic designers, illustrators, photographers, and so forth, that, that's why you have a portfolio.  You have a portfolio so that the client can decide whether to hire you, but if they hire you, they've gotta pay you for your work.  Whether or not they use it, whether or not they like it, you have a right to be paid for your work.  So I think that's why--I feel that's probably what they're reacting to.  

Atwood:  No, and I agree, there's definitely concerns, but my hope is that the people entering the contest are not--this is basically a day's work.  So, somebody, for a day's work, is getting $512.

Spolsky:  Not even a day's work.

Atwood:  Yeah, and my thinking is, OK, you're taking a chance, you're not putting too much effort into this.  This is iterative, kind of brainstorming kind of design.  You're not gonna spend a week coming up with this comprehensive--

Spolsky:  So we had, what, like 250--

Atwood:  It's over 200, I think it's 220 or so entries.  But a lot of them are derivative, a lot of them are just--and some of them are really bad.

Spolsky:  So they're getting $2 on average.  The average person can expect to make $2. [laughs]

Atwood:  So, not all work is created equally, and not all income is distributed equitably, this is just the way the world is.  So hopefully if you entered the contest, you knew what you were signing up for.

Spolsky:  Oh yeah, and as long as they know what they're signing up for, that's fine.  I suspect that people probably won't do this too much unless they start winning a lot more often, and I think probably the average contest will have a lot fewer entries than ours, because they won't have you publicizing it.  But, the ones I liked, in terms of the logos, what I was looking for myself was what a stack overflow really is.  There were a lot of people that kind of had this idea of something toppling over, or spilling over, or falling over, and that's not really what happens in a stack overflow.  I mean a stack overflow is all about overwriting something.  In other words, you've got this stack, and it's growing, and it continues to grow, and it doesn't fall over, it just overwrites something important.  And nobody really quite captured that.  Some people did at least capture the idea of a stack that grows too high.  And there's nothing wrong with the overflow metaphor.  As it is, I don't think anybody's really going to object to it, it just doesn't really--to a programmer that knows what a stack overflow really is, it's sort of weird.  It sort of looks like a graphic designer's impression, based on what the word overflow means in English, rather than a computer scientist's impression.

Atwood:  You're not going to like what I'm about to say--

Spolsky:  No.

Atwood:  --but I believe that most of the people reading StackOverflow ultimately, longer term, will not understand what a stack overflow is anyway.

Spolsky:  [laughs]

Atwood:  So I think it's--

Spolsky:  It's that error message you get when you try to write C code.  [laughs]

Atwood:  [laughs]

Spolsky:  "I don't know what it means.  It's like, run your program, it's a stack overflow."

Atwood:  People submitted a very funny AMIGA--the AMIGA had this very funny guru meditation error message, and somebody submitted a stack overflow in that format, which was very amusing.  So yeah, you're right, a lot of programmers have seen stack overflows in terms of the error, right?  You do too much recursion, right, or you forget to exit your recursive loop, and your stack overflows.  So I think they're familiar with the error message, but the actual technical underlying details, like details of C, I think are gonna be lost on a lot of people, for better or worse.

Spolsky:  I think it's almost always an infinite loop.  It may also be caused by just  a limited size stack, and you're trying to put too many things on the stack.  But 99% of the time you see it because you're in an infinite loop.

Atwood:  Right, no, that's a great observation, and I'm very glad that we covered that.  So, how many questions do we have this week?

Spolsky:  As many as you want!

Atwood:  OK, we're a little long, so we wanna be careful. So let's go ahead and get on to the questions.

Spolsky:  OK, let's see what we got here.  Let's start with Dave in Vancouver.

[39:25]

Dave Kauffman:  Hi guys, this is Dave Kauffman, sending in from Vancouver, Canada.  Joel, it's great to hear the sultry tones of your voice on the podcast, rather than just written, so I'm looking forward to supporting the podcast and hearing more episodes.  Here's a question--

Spolsky:  Dave is somebody that I know from, I guess he worked at Creo-Cytechs, which is a publishing software company in Vancouver.  I don't know if he's still there, maybe he'll tell us.

Kauffman: --for you.  I think you've written before, and I tend to agree, that computer science as a science in universities is quite inappropriate.   That is, people want to really study the science of it are very in the minority and need to be at universities.  But for the most part, we want good practitioners in the craft of software development, and software engineering.  And that may not be the right place for them when they're trying to find theoretical backgrounds for things that are heuristic.  So my question for you is, is there any real-world use for recursion, or is it just kind of one of these kind of made-up, interesting things that should stay in academia?

Spolsky:  Well, there's definitely a use for recursion, it's just not as common as you may think.  But when you're writing a compiler, you definitely need to know how to use recursion.  

Atwood:  Yeah, it's an unusual choice, I think, in mainstream programming.  I think it's definitely something you want know about and understand.  I think more so than pointers, certainly.  I think that recursion is a very fundamental concept that programmers need to understand.  But yeah, I think it's less common in the wild than people who practice computer science--

Spolsky:  Somebody who's working in a typical insurance application top-level, is unlikely to ever need to recurse.  Although you might, if you're getting some data in an XML format, and you need to kind of, things can include other things--you may have to write some recursive code, you probably will.  I'm willing to go so far as to say that recursion is a fundamental concept.  On the other hand, there's a lot of stuff in computer science, like lambda calculus or even linear algebra--which is often taught as a part of the computer science curriculum--synchronization primitives, that you're probably not ever going to use, that are just a little bit too theoretical.

Atwood:  There's also this big divide--and you also spoke at this Canadian conference that I was invited too, CUSEC, and one of the things I found out there was, there's a huge controversy in Canadian universities about computer science, as a discipline, versus software engineering as a discipline.  I don't view them as different, but they have a set of terminology and a set of classes that are specific to those two things, and it's hugely controversial.

Spolsky:  Well, there's no question that they're different.  Computer science is a field of academic study that has pretty much been unchanged since the 70's--I would even go back to the 60's in terms of the core curriculum--that is an academic course of study that in liberal arts institutions is intended not necessarily to be preparation for a career in programming or in software engineering or software development, but to be an academic discipline of its own right, with its own set of important things that you need to know and results, and the kinds of things you do in computer science include proving theorems, proving that programs never halt, for example, stuff that was relevant to what computers were used for, maybe in the early 70's occasionally, but honestly are not really related to what a software developer does today.  So I disagree, I think that computer science is a reasonable preparation for a career as a software developer, and especially if you go for the whole idea of liberal arts, that you're going to a university to learn a lifetime worth of skills that are generic skills you'll be able to use everywhere, then computer science is a pretty good way to learn how to be a software developer.  And for all practical intents and purposes the elite of software developers generally have a computer science education.  Not always, but often.  That's very, very different than software engineering.  The stuff in software engineering that probably every working programmer should learn.  How to design user interfaces that are easy to use, for example, is something that has almost nothing to do with computer science, and is not a part of traditional computer science, and should be a part of every reasonable software development or software engineering curriculum.  

Atwood:  And I think with academics, you have a lot of the same problems of practitioners versus people in the ivory tower studying.  And so I think you gotta have a mixture of thinking and doing.  So as long as you have a good mixture of those two disciplines, I think you're gonna be fine.  I don't think the terminology--I get annoyed by the fact that people really harp on this terminology issue, and I think it's more about what you're doing, versus what you call it.

Spolsky:  In defense of the Canadians, it was pretty much the students in Canada who lobbied for a software engineering curriculum to be available.  And that was because they were directly complaining at the irrelevance of many things in computer science to being a software developer and the computer science department's inability to teach kids things like source code control, to teach them code hygiene, to teach them anything about working on a team of software developers.  The computer science curriculum as it developed just wound up being a different thing.  Y'know, it's like trigonometry versus civil engineering. At its heart, there are probably two or three classes that you both wanna take, but fundamentally, they really are different courses.  And more power to them.  It's sort of interesting that that was a student movement in Canada, that they were actually able to sort of persuade their universities to create this true engineering curriculum for software engineers which, I'll bet--I don't know the details, but I'll bet probably only has about a quarter of the courses in common with computer science.  

Atwood:  Yeah, and I love the message there, because it really is--I was appalled to read that a lot of computer science--or whatever you call it--degree students had no practical experience with source control.  And that is as fundamental as it gets to the practice of actually writing software.  And I felt like that was a huge oversight.  So it's a tremendous credit to the Canadian students that they forced this issue.

Spolsky:  That actually segues well into this call, I'm gonna play another call, from Nick:

[45:43]

Nick Malaguti: Hi, my name is Nick Malaguti, and I'm a computer science student at Stevens Institute of Technology.  I'm going to be a senior in the fall, and in order to graduate we are required to complete a team project.  I'm not a fan of doing real-world projects as an academic exercise for two reasons.  One, there is no real hierarchy within the team, because everyone involved is a student, and two, if the project cannot meet the hard deadline at the end of the semester, it is not possible to move the deadline and still complete the project.  Since you have both worked--

Spolsky:  That's real life.  Both of those are real life, I'm afraid to say.  In real life, software development teams often don't have anybody who's in charge, and they are teams of peers.  And also in real life, sometimes you have to ship, y'know, you have to ship at the end of the semester, whatever that may be.  If you're working in game development, for example, that's about as hard a deadline as you can get.  If you work for the IRS, when you have a coding deadline, it's extremely hard.  

Malaguti: --professionally in software development, what steps can I take as a project manager to mitigate these constraints and still complete the project successfully?  Also, if you can recommend a free project-management software solution, I would really appreciate it. Thank you!

Spolsky:  Woo, FogBugz, FogBugz! So, first of all, second of all, FogBugz is free for students: you go on to FogBugz, you make a free trial, and then send us an email and say, "Hey, I'm a student, could you please extend my free trial," and what we'll do is, we'll make that free trial last all semester for you, or all year, until your project is done.  That was the second question.  What can you do to mitigate this? I actually think that learning how to work on a team with no--a team of peers where there's nobody in charge is a really important skill, and a really important and valuable thing to learn.  

Atwood:  Absolutely, I think you answered it almost immediately straight away.  I think part of his question is wishful thinking that there's this idea that out in the "real world" you don't have to deal with these crazy people and these crazy problems, but I think you'll find that the academic world, in college is like as good as it gets.  I mean, it doesn't get better when you get out in the world, right?  So learn to deal with the problems there, because you're gonna have a lot of the same stuff.  And everything is, to a disturbing extent in the world, personality-driven.  So the more you can learn to deal with that, I think, the happier you will ultimately be.

Spolsky:  Being able to get things done--there's a book, not the best book in the world, but the title of the book is great, which is, "Getting Things Done When You're Not In Charge"--and this is one of the most fundamental skills that you can learn in life, getting things done when you're not in charge.  We have a management training program, a small management training program here at Fog Creek, where we train people that wanna be managers of software companies, and managers of technology, and it takes me a while to explain to them that the way they're going to learn to manage is not by being put in charge of a project, but rather by building their own reputation, and getting people to listen to them simply because they're right.  In other words, they have to learn how to get things done without being in charge, which will make it easy to get things done when they are in charge later.  

Atwood:  Yeah, it's a great question, let's do one more.

[48:36]

Spolsky: OK, another question.  I don't know if I have another question.

David Alison: Hi guys, my name is David Alison.  I live in Ashburn, Virginia.  I have, er, I'm really excited about this show, this sounds an interesting idea and I'm interested in seeing how it evolves.  The question I have for you is: as a .NET developer that does web based solutions, I'm curious how you guys look at things like the Google App Engine and the impact you think that's going to have, you know do you see that evolving on the .NET side where people will be able to at some point from within a solution or a tool like Visual Studio be able to deploy their application to a scalable hosted solution easily, and as I've been doing web based development for a long time and that is probably the single most difficult thing, is actually, er, it's not building the application, it's supporting it, it's scaling it on the back end, it's all of the IT and infrastructure you have, and that's something that the Google App Engine kind of makes all go away, or the promise of it is very straightforward.  So I'd love to have you guy talk about that and hear what both of you think on it.  Thanks.

Atwood: I can start a little bit on that one.  So I think what Google and lot a lot of other companies are doing now are simply removing what I call the software installation barrier, where everything just runs out of the box, there's no software to install, it's sort of like the browser model of do you install, you know, Facebook?  No you don't you just go to the Facebook website and everything just works.  So, with Google App Engine, you know, all your development would essentially be ready to go out of the box.  Like there's no ... Think about what I had to do with StackOverflow.  I had to install Visual Studio, I have to secure a dedicated server.  All these intermediate steps I have to to get my app go live on the web.  Whereas with something like Google App Engine, you go into your browser, you write some code, and then bam, it's consumable on the web almost immediately.  So they just removed a lot of the intermediate steps.  To me that's what I see it as.

Spolsky: Er, that's clearly the goal.  That's obviously what they're trying to do. We go a long ways to go there though.  The first issues are, if you're going to write code that can be automatically scaled, you have to write code with constraints.  For example if you like relational databases, you can just forget that, 'cause you don't get relational databases anymore.  A relational database doesn't scale beyond a single box, basically.  There are ways to do that, but you don't get the real linear scalability, so you've got to work with a very very different database model that is not nearly as flexible as what we're used to from relational databases.  Maybe it is.  Maybe it's better, who knows?  For all intents and purposes though, if you look at like Amazon DB, that stuff is all incredibly weak compared to what relational database programmers are used to being able to do.  So if you were writing a new project from scratch, you might want to develop it for one of these systems.  Right now, it seems a little bit scary and I haven't really gotten over this, which is: would you really build your mission critical business applications on ... you know at what point can you actually start trusting Amazon or Google or Microsoft now with their Mesh thing ... at what point would you really start trusting them to be there with the reliability that you need?  I mean I suppose they could probably  ... There's a bunch of different aspects to this.  One is I assume they could build something more reliable than you could in most cases, so that's good.  On the other hand, what if Google suddenly decides they don't want ... you know they want to charge more.  You're sort of stuck, you have to pay them, they're kind of the monopoly provider.  Or what if they decide they want to charge you by the byte and they used to be charging you by the kilowatt or something. 

Atwood:  Certainly there's an issue of scale.  If you're going to be really big or, have an independent entity you want your own server you can totally control.  You don't want those constraints by potentially one of your competitors, right, I mean that's certainly something to think about.  I know in terms of blogging, one of the things I first recommend to people is get your own domain name.  Do not let your name be owned by blogspot or blogger or whatever

Spolsky: Yeah, cause you're going to regret it.

Atwood: You're going to regret it, you going to have no flexibility. You can't move.  All that stuff.  So I think that's a concern as well.  But I do admire what they're doing in terms of removing the barriers to getting things done as a programmer and just putting stuff up on the web.  I definitely admire that and I think being not tied to the executable view of the world like Microsoft is, and the desktop view, is really a strength for them in terms of getting more stuff out there.  I don't know what the quality will be but I think it's certainly valid and something Microsoft-

Spolsky: I mean we might, and I hate to be an architecture astronaut here, cause this is all architecture astronaut-ure.  This is architecture astronomy of the first degree.  That said, I kind of feel like these development environments built ... Right now if you develop on Google your code is not portable to Amazon web services which anyway provides a different set of services than Google provides.  It's not really portable to anywhere.  You develop on Amazon Web Services, it's not portable to the Microsoft stack.  You only have one provider, they're all providing a very very different set of services.  Many of them are trying to provide the same thing in kind of non-overlapping ways.  And this is very much like the platform wars of the olden days.  And until there's something reasonably standard that you can get multiple providers for or that everybody's using anyway, it's kind of like a lot of people won't place their bets until they see who's going to win.  Because there is this terrible risk that Google will suddenly realize that they just can't win in that business, there's no way to make money in that business and they just shut it all down and they tell everybody you've got three months to get your stuff off 'cause we're turning it off and if you've built a business of that then you're in trouble - to put it lightly.  So right now I think a lot of the more conservative businesses and a lot of the more careful businesses will be saying , "I don't need another dependency, yet another way my business can be ruined. I'm going to build something that I control or I'll wait and see who wins here". Sort of like the Blu-ray vs HD-DVD wars.  People won't jump in until it's clear that there's going to be a winner. So there's going to be a lot of thrashing this out as these is very, very 1.0 if not 0.0 versions of these services come out and they're a lot of fun to play with and you know, when version 4.0 comes out and it becomes clear what the technology choices that most people are making, and it becomes clear that there's a sustainable business there for the platform vendor so the platform vendor's not going to go away then I think only at that point will you see the masses actually converting to this model of development.

[56:01]

Atwood: But Joel, do you see this as a winner-takes-all type of scenario, I mean, this is the new world of infinite bytes, there's not these plastic disks that have to be distributed and carried at BestBuy, do you really see it as this old-world winner-takes-all?

Spolsky: No, I don't think it has to be a winner-take-all scenario, no.  Not necessarily.  On the other hand, the truth is a lot of the companies getting into this business, I guess there's not so many - Amazon and Google are the most prominent - and I guess there are a lot people that provide things like, there always places you can get a virtual machine.  Even a virtual server that you get from Amazon where you basically configure it yourself, is something that's generic enough that you can imagine getting that from someone else.  In the case of Google they're really giving you a special and unique programming environment that it would be very very hard for anyone else to reproduce, so if you've created a crap-load of code for Google you're not going to be able to move it to somewhere else with any reasonable [indistinct]

Atwood: Right.  Don't people say the same thing about Microsoft, though?  That, like, you're part of the Microsoft ecosystem so you're totally locked in?

Spolsky: It depends on how you've selected your Microsoft [sic] and that can definitely happen.  On the other hand, if you write .NET tools you've got Mono at least.  You know, there's another implementation.  You're writing Windows code not because you have the ability to port it easily to somewhere else, you're writing Windows code because that's where your users are.  You need to run on Windows because that's what people have, you just don't have any choice in that matter, and people do have it.  So maybe it's not winner-takes-all in the sense that there's certainly a healthy ecosystem for Apache and IIS, there's lots and lots of different webhosting technologies, there's no reason you can't pick one, on the other hand there is sort of the risk that these vendors will lose interest.

[58:10]

Atwood: No, it's certainly a very interesting development.

Spolsky: I have to say, from experience, it's years and years away, and there's definitely going to be, in two weeks you're going to see 37 dumb little twinkie little startups that do something like order Twinkies over the Internet, showing up on TechCrunch all of which were built with Amazon webservices, and the minute you see them getting listed on TechCrunch you'll go there and you'll see whatever Google's error message is for an application that uses too much bandwidth or too much CPU power and that's all you'll really ever see of these services and that will be the end of that.  That'll be this first euphoric wave in which dumb things are built and they never go anywhere.  But I really do strongly believe that whatever the core services that you're building, you've got to build it on tools that you either control or that are available from multiple sources or that you totally trust.

[59:07]

Atwood: Right.  I love, I know you had a classic post about Excel, and how they had this really radical dependency-rejection culture.  I think that's important to cultivate, you have to choose you dependencies very very wisely, you're going to have them, everything's a dependency, you have a CPU that you run on, and all that stuff.  It's something you really want to think about and give due diligence to, but-

Spolsky: "find the dependencies and eliminate them" was their motto.

Atwood: Where you can.

Spolsky: I don't remember them saying "where you can", I think they said "find the dependencies and eliminate them" - that was pretty much the end of their motto.

Atwood: We're not as hard-core as the Excel.

Spolsky: You know, if they really believed in it, they'd be selling you an Excel box that you bought in a box from a Microsoft store.

Atwood: I think actually they'd be running in a virtual machine, which I don't think is actually that far off in the future.  But I think - I have this radical theory - that everything will be delivered in a virtual machine eventually.

Spolsky: That'd be really nice.  That's not a bad idea, and definitely you'll see FogBugz moving not quite to a virtual machine, but we're going to package a lot more of our stuff on Unix we're probably going to start chipping our own version of Apache just to run it on a different port.

[1:00:20]

Atwood: Oh sweet! You guys are gonna have...

Spolsky: Uh huh.

Atwood: ...the FogBugz distro?  When someone installs...

Spolsky: Something like that.  I'm not really sure.  I, I shouldn't talk about this until it's designed, actually.  But, y'know, we are trying to, actually, at least have a distribution that, that includes more parts of the stack so that out of the box, if you don't mind just throwing our stuff on there uh, you'll get something that has been tested together and works and if you really need to use the Apache that's on your system, then... ok, but, but, but if you don't, then you don't.

Uh, okay, so before leave I just wanna um, uh, uh, er, once again encourage our uh, listeners, if you have any questions, comments, uh, or anything you want us to play on next week's podcast, to uh, make a little MP3 recording or Ogg Vorbis um, and email that too...

Atwood: Podcast@stackoverflow.com.

Spolsky: ...podcast@stackoverflow.com.  Uh, if you don't know how to record an mp3, let me just play this...

Tim Patterson: Hi, Joel and Jeff.  This is Tim in Austin, and I heard you guys talkin' about how people might record their audio uh, to send you questions and that.  And I found a thing from Dave Weiner's site called blogtalkradio.com.  And, basically, if you go there, it's got a phone number; you can call in, like I did just now, uh, record whatever you want, hang up the phone, and then it uh, outputs your recordings in a simple RSS feed.  It's got a little link -- on the page -- to an mp3 of your audio which I'm about to send you...

Spolsky: It's real easy.  Blogtalkradio.com: you call a phone number and then it puts up that mp3 recording at a url that is the phone number you called from.  So, basically it's an extremely easy way to make podcasts.  If you wanted to make your own podcast you could just basically call that number every time from the same number... and that phone number -- your phone number -- would be your podcast's url.

Check it out.  Very easy: blogtalkradio.com or just use the microphone on your computer, record an mp3 uh, and uh, send it us.  Um, stereo is not necessary.  Maximum time: 90 seconds... um, even less 'cause y'know I gotta go through a lot of them and figure out what to play.  Thank you very much, and we'll see you next week!

Atwood:   See you next week.