The StackOverflow Podcast

Intro, advertising

[1:06]

Spolsky: I was listening to Adam Curry and John C. Dvorak going at it.  They have a podcast that's pretty good called "No Agenda."  And they were talking about how the Skype thing, Adam Curry is in England and John C. Dvorak is in California, and when they do Skype there is like a half second delay there. Or a second delay.

Atwood:    Wow.

Spolsky:  They were talking specifically about that phenomena, of how that little bit of latency makes it seem like the other person isn't laughing at your jokes.  They are sort of begrudgingly conceding, maybe after some thought to provide a little bit of simulated laughter.

Atwood: [chuckle]

Spolsky: because of that slight delay there.

Atwood: Oh yeah, latency is evil stuff, no doubt.  Conversation destroyer.

Spolsky: if we ever get anyone to listen to our podcast, apparently you can switch to ISDN, and you get no latency.

Atwood: Well we're only going across...We aren't going across an ocean like they are.

Spolsky: We aren't going nearly as far. Well I think most of the problem is the uphill bandwidth out of Fog Creek, coming out of Fog Creek, which is shared by a lot of people and that problem will go away after we move offices in a few months.

Atwood: You guy's should upgrade your AOL dial-up connection to something, you know like ISDN.

Spolsky: I hear they have 14.4 now, instead of 9600

Atwood: [chuckle] Exactly. So I have something from the previous show, you mentioned that you are an honorary Kiwi, an honorary New Zealander.

Spolsky: Not honorary, no I'm an actual New Zealander, I never said honorary, there was no honor.

Atwood: Well, there is.

Spolsky: It is great to be a New Zealander.

Atwood: Alright, well explain please.

Spolsky: [chuckle] What, what, what?

Atwood: Well, why are you a New Zealander? You're not from... That was not mentioned in your Wikipedia entry, I cannot believe it to be true.

Spolsky: [chuckle] My father is a New Zealander... Do you want me to show you my passport? Good God!

Atwood: No, I didn't know this about... You're really a New Zealander?

Spolsky: Yes. I'll tell you the story. My father is a New Zealander, and for brief period of time, I don't know if this is still true, actually it is still true, before they had the Internet if you wanted to visit Australia, which I did, you needed a Visa as an American citizen. Nowadays you go on the website and you pay $10 and its done, but you used to have to go to their Consulate in person and apply for a Visa to visit Australia and I went to the Australian Consulate and stood in line for hours and hours and hours and this was the Consulate in Rockefeller Center in New York and I noticed that there was no line across the hall at the New Zealand Consulate because they don't require Visas. So it occurred to me that maybe New Zealanders don't need Visas to visit Australia. So I went to New Zealand Consulate and asked if it was true. And they said: "Indeed. New Zealanders can visit Australia without a Visa". And I said:"Well, I wanna be a New Zealander. My father is a New Zealander. Can I get a New Zealand passport?" And they said: "Certainly, Sir. Go down to the basement, get some pictures taken, bring them up". And I did, and they did, and they made me a passport.

Atwood: That was nice.

Spolsky: That was very nice. So now I'm a New Zea... I mean, you know, by birth, I guess, I'm a New Zealand citizen.

Atwood: Oh, very cool. I didn't know. I know that FogBugz has the kiwi logo.

Spolsky: That's right. That's the part of the reason. That is a national flower, actually. People think it's a national bird, but it's a national flower in New Zealand.

Atwood: The kiwi is a flower?

Spolsky: No. Just kidding.

Atwood: Ok. [chuckle] Looks lot like a mammal.

Spolsky: [chuckle]

Atwood: I'm not a "scientist", so I ___

Spolsky: It's not mammal. It's a bird! It's a flightless bird. And that's his bug, that's why it's FogBugz. Get it, it's a bug: He can't fly.

Atwood: He is very cute. I do actually enjoyed that aspect of. And he goes sleep at night, which is, frequently, when I'm using system.

Spolsky: Oh, I'm glad that you noticed that, that's a good sign.

Atwood: Yes. Totally. What about the name "Fog Creek"? Why "Fog Creek"? What's fog and creeky about New York city?

Spolsky: Yeah. Well, we had a little creek in our original office. We called Fog Creek.

[pause]

Atwood: I'm not getting it. You actually had a creek?

Spolsky: Yeah, just like, well... more of a leaky faucet, I guess. Not a "creek" so much as a "dripping faucet that could not be completely contained".

Atwood: But surely naming, I know, naming is really difficult. And so much thoughts goes into this names. So what — is the nether meaning to the name?

Spolsky: Um. No.

Atwood: Ok.

Spolsky: Yeah.

Atwood: Just... Ok. I'm a little disappointed, I've gotta tell you.

Spolsky: [chuckle]

Atwood: Not quite as exciting as I was hoping it would be.

Spolsky: You know, this things go in waves. You know, different trends. As time goes on it becomes different things become, right now it is very important to have something that's unique in Google. And to be able to get a domain name which is why you get all this [cthulhu sounds]. And thats an actual name of a Web 2.0 startup.

Atwood: Well, that's a little scary.

Spolsky: Yeah, it's just a lot of Q's and X's and the Hebrew letter Heth.

Atwood: So I wanted to give a shoutout.  Somebody sent in a question recording and I totally abused their trust and stole their topic and posted it on my blog.  This guy, Yuvy?

Spolsky: Yeah

Atwood: He sent us a link to the Spartan Programming that I liked so much that I kinda stole it and put it on my blog.  But he sent us recordings as well so then I felt really guilty.

[6:25]

Spolsky: Spartan Programming - I saw that on your blog and I thought, you know, it's true really, we only really hire programmers with great abs, here at Fog Creek, and I'm in favor of that policy.

Atwood: Yes, well you know I went through a period where I actually wasn't really writing a lot of code, and now that I'm working on StackOverflow I actually am spending quite a bit of time in Visual Studio now, and it was just interesting how I was reading through that, the whole principle of sort of minimalism when it comes to code.  Now it's not — you can obviously take it to an absurd degree where you're inlining everything and... but within reason, I mean minimalism is definitely is where I've been going with my code over the last five to ten years, so it was just kind of fun to read that and have sort of a word that describes that philosophy.  And then somebody pointed out to me that Steve Yegge had written basically the same post, but like in 4000 words.

Spolsky: [chuckles]

Atwood: It's funny because... and I read it and I was like, "No, you're right", that basically is the same thing as Spartan Programming but , you know, much, much longer.  And it's ironic that — and poor Steve — oh, by the way I did contact Steve, he might be able to, if we want to have him on the podcast as sort a guest,

Spolsky: Oh, great!

Atwood: ...in like a month or so... he's got like a vacation, and then he's got some deadline at Google that he's working on.  But I would love to have him on because we talk about him all the time and I kind of feel like he's here even though he's not here.

Spolsky: He's watching from the ceiling, like ceiling cat 

Atwood: I don't know why that is... [garbled]

Spolsky: On the topic of Spartan Coding I've been noticing the same thing, the same kind of phenomenon, I haven't given it a trendy name, but in Visual Studio, or actually ASP.NET programming with C#, in version 2.0 it got possible to do a lot of things in very concise declarative ways, so an awful lot of web pages that just present, do basic CRUD stuff, you know present data, and format data, and just let you edit, update and delete data.  Absolutely stunning how much of that can be done entirely by declaratively creating these tags in your HTML file, much of which can be done with actually a graphical designer, so actually sitting with your left hand and just using your right hand with the mouse you can create, you know, fairly complex CRUD apps in a way that's really awesome.  And I've actually found that my old crappy code is the code in which I have 20 or 30 lines of C# doing something, and the elegant new code is the code where there's almost nothing in C# and almost everything is in the ASPX file, in the form of, what do you call that? ASP.NET HTML? Embellished HTML?

Atwood: I don't know if there's a word for it, but I know what you mean, it's basically a hybrid of HTML markup and then server directives.

Spolsky: Right, but they're not even really server directives so much as like these custom tags, and the way ASP.NET works is that each of these tags, at run time, becomes an object, it gets created as an object, and all of these objects are nested in each other in the same way that your file is, and then some magical sequence of events happens, cascades over all these objects, and then generates your final page.  And it might call into your C# code, but it might not.  And I actually thought, I'm sure that you, by this point you already read Marco's reply to, to...

Atwood: Ooh, no I hadn't seen that actually, I'll go look that up.  Is it on his Tumblr blog?

Spolsky: Eh, probably.  Anyway, he said, basically, that we're idiots for using ASP.NET, and that we should be using PHP like everybody else, it's perfectly good, and... Marco, you are wrong! You sir, are wrong.  PHP is a generation behind ASP.NET.  ASP.NET version 2.0 with C#.  Writing web apps like that is like driving around in a Lexus SUV, and you PHP guys are like riding bicycles.  Just wanted to say that.

Atwood: Oh, this is cool: I'm reading it now.  My lyrics are bottomless.  So, let me tell you Marco, if you're a Flight of the Concords fan, we can never be enemies, because I love everybody who loves Flight of the Concords.  So we'll always have that in common.  But I've really warmed up to the concept that, the whole thing about you know, "PHP sucks but it doesn't matter". It really is true.  I think it's possible to write good code in PHP and produce some really amazing sites.  

Spolsky: But you know what, ASP.NET, it's like having electric windows, and electric locks, and leather seats, with air conditioning, with cushions, and ahh!!  It's just a luxurious experience, and you pay for it, because you're going to have to pay $800 to put Windows on every server in your data center, so it's the expensive option, but you get your money's worth.

Atwood: Well the one thing I will say is that compiled performance is, I think underrated a little bit by the people who do dynamic stuff, because the way it is now, with compilation, you have to really really screw up to cause yourself a performance problem, whereas in PHP I think you have to be a lot more careful because everything's interpreted. And people always forget that these interpreted languages, it's like a factor of 100, the performance difference, I mean literally, like in McConnell's Code Complete 2, when he did the rewrite of Code Complete he put in examples in like Python, and I thought it was PHP, but the point being he was comparing compiled to interpreted and the difference is still as large in relative terms now as it was back in 1993 when he originally wrote that.  It's just fundamental to - I think - the science of languages.  I mean, there's a lot of really good work going on around Javascript to make it faster, but I think there's a limit to what you can do, and people underestimate the performance difference you're going to get.  Now, that said, you're going to spend most of your time talking to the database anyway, right? So... I think it just lets you be a little more loose in the way that you program and not have to worry about performance as much.  I mean, to me that's, I think one of the major differences. 

Spolsky: Right.

[12:14]

Atwood: But yeah, that's cool, I'm glad you pointed that out. Because I had looked for a response, but I didn't see one.  I'll have to read that at some length later.

Spolsky: [Chuckles]

Atwood: Let's talk a little bit more about StackOverflow and where we are.  So people are asking about the Beta, and you were asking about the beta.  So in the last podcast I snuck that in at the end of the schedule.

Spolsky: Yeah ... There's another thing Marco is wrong about ... Yeah we could just rant and rail on him. He was also saying that we're all idiots for doing this whole thing in the dark, instead of showing it to people and doing incremental whatever, and of course we're going to show it to people and do incremental things so .. he's just wrong. Wrong.

Atwood: Well, right, right. So let me talk about that. Because you said, "it can be missing limbs" - which is - there's all these disturbing analogies like "we're going to flesh something out," what do, we start with a zombie and we just start grafting flesh?  It's disgusting!

Spolsky: You start with a skeleton, and then you start - basically you get one of those things that the builders use to put glue behind the tiles... spatula! What are those called? Spackling knife, and you start slathering the flesh onto the skeleton.

Atwood: Right. See, I've already lost my appetite just from that description. It's horrible.

Spolsky: Disgusting.

Atwood: Yeah, it's a little disgusting. A little maybe too exciting. So, my feeling with StackOverflow is that we've identified a few set of core features that I think are important, that have to be there. And one thing I've noticed, and this is in no way meant as a dig on our audience or anyone, it's just really human nature, people can't comment on things they can't touch and see and use. They cannot give you meaningful feedback on a drawing - or the worst is a verbal description, right, because people don't really listen.

Spolsky: Well they sure try, don't they? [chuckles]

Atwood: Well, first of all, people don't really listen to you. They hear half of what you're saying, half the time, maybe on odd numbered weeks when you have a full moon.

Spolsky: [chuckles]

Atwood: But having something that people can touch and use is where you get valuable feedback. So one of the reasons I'm pushing back slightly on the schedule. So, just so everybody knows where we are, the original plan was to have the beta this month. We might be able to do that, maybe at the very, very end of the month, but I think it's looking more realistic that it's going to be slightly into next month, maybe 2 weeks? And the reason for that is editing. We haven't gotten to editing at all, and it's a huge part of the system, right? Like, we've talked about how much we admire Wikipedia, and how blog posts get out of date because you can't effectively edit them. So this really has to be there, even from the aspect of, say I post something, and I make a spelling mistake or something stupid - I've got to be able to go in and change my stuff. 

[14:42]

Spolsky: I don't believe that has to be there on day 1.

Atwood: Well, I do though, because the whole ... keeping the system alive, plus being able to edit your mistakes.

Spolsky: I've had discussion forums for years where people can't edit their mistakes, and they survive and they get an audience.  It's not the end of the world.

Atwood: This isn't something that's gonna take us a month to implement. I think it's gonna be more like a 2 week thing to really get it working. But that's the main reason actually.

Spolsky: Nobody's gonna have enough karma to edit in the first 2 weeks anyway, so just launch without it, we'll wait till people get the karma, and we'll tell them that they need even more karma before they can edit [chuckling].

Atwood: You don't need karma to edit your own stuff though.

Spolsky: Oh I see. Weren't you going to make, like, a 30 minute rule or something like some people have. You know what, Jeff, people launch these conversation things all the time without editing. And sometimes they even see it as a virtue, where they're like "this makes people extra careful about what they post, because they know they're not going to be able to edit it. So they double check it three times."

Atwood: Well, I gotta tell you, the way Twitter works, there's no way we can have worse down time than Twitter. I feel like whatever we do, it'll be better in terms of uptime than what Twitter has.

Spolsky: Does Twitter have editing?

Atwood: No it doesn't.

Spolsky: Ah-ha!

Atwood: Well, you can delete your tweets though, which we don't even allow.

Spolsky: They're out there, they're gone, they're in the ether. It's like un-sending an email.

Atwood: OK, so the official statement of record is: maybe this month if the stars align correctly, but more realistically, definitely by the middle of next month (I think). I mean I've talked to the team and we all sort of have a consensus that we believe that's an achievable timeline. So the key pieces are all there, so people can actually give us meaningful feedback on all the features.

Spolsky: OK.

Atwood: Plus, it's a big beta. There's like 350 people on my beta list now. Plus my friends and your friends. I assume people at Fog Creek would be allowed to go into it. So this is like pretty big.

Spolsky: On weekends, from home.

Atwood: [Chuckles] This is gonna be full of useful things that will help them do their job 'though.

Spolsky: Let me play a question, that's kinda related to that, cause the answer to that question is the next thing I wanted to say.

[16:41]

Isaac Moses: Hi, this is Isaac Moses in Baltimore, Maryland.  Thanks a lot for the podcast, I'm really enjoying it.

Spolsky: Do we have a lot of listeners in Baltimore?  It seems like all these questions are coming from Baltimore.

Atwood: I don't know.

Spolsky: Maybe there's something wrong with the... maybe we're being blocked in the rest of the United States.

Atwood: I'd like to hear the rest of the question.

Spolsky: Yes.

Isaac Moses: How do you plan to get people who know stuff to keep coming back to your site, and find questions that they know the answers to?  Thanks, 'bye.

Spolsky: Yeah.  I don't [garbled] a problem.

Atwood: Ah!  This is... this is a feature that's near and dear to my heart.  'Cause I just implemented, uh, what will be called badges, so...  I am also a big fan of the Xbox 360, I believe it is one of the best products Microsoft has released in a long time...

Spolsky: Do they call them "badges"?

Atwood: ...much better...Ah, they're called "achievements" in the Xbox 360 system, and it's amazing how seductive these things are, like, when I read about this, I came late to the Xbox 360 'cause I was trying to get the most out of the last generation of gaming platforms...

Spolsky: [chuckles]

Atwood: I don't really like to buy a lot of consoles, it's just — there's a lot of hidden costs, and I'm really a PC gamer, I'm sort of a, again, I'm a snob, I'm a hardware snob, so of course I'm not gonna be into that, but Rock Band really pushed me over the edge.  And one of the things I found after reading about achievements, I was like, "Oh, that's dumb."  You know, as you play the game, you do things, and you get these little badges, these achievements that show up in your profile online, so people can see them.  See, that's the key thing — other people can see them, that's the really important piece of this.  I was like, "Oh, that doesn't matter."  And then, as I played the Xbox 360, I got these achievements, and I became totally obsessed with them.  I was like, "I have to have all these achievements for these games that I like," right?  Because I just, I want them, I must have them! [laughs]

It's amazing how quickly I turned around on that, so when it came to StackOverflow, I was like, I want to have something like achievements in StackOverflow.  So we have this "badges" system, which is very much analogous to Xbox 360 "achievements".

And there's really three roles that these things play.  The more I played games on the 360, the more I understood the genius of the achievements.  They do three things.

One, they encourage people to do all the things that the game lets you do.  Right, so some people will play a game and like never do some big piece of it just 'cause they never see it or never get around to it or whatever.

Spolsky: Seems boring when they're looking at it from the outside.

[pause]

Atwood: It totally seems boring from the outside, but I'm telling you, once you get in, it's so seductive...

Spolsky: No, I mean that part of the game may look like, "Oh God, I don't wanna go into that room, that's crazy."  But then, say there's a badge there that you want.

[19:04]

Atwood: Or, yeah, like, "Why would I bother with multiplayer, I don't enjoy multiplayer," but there's a multiplayer badge, so you're like, "Well, it's not too tough to get this entry-level badge so I'm going to go do the multiplayer," and then you might really enjoy it or, y'know, you might think it sucks or whatever.   So along those same lines, on StackOverflow you will collect badges — what I call bronze badges — for doing the basic things you can do on StackOverflow, such as voting, asking a question, answering a question.  Tagging something as offensive gives you a Spam Cop badge.  So you will be rewarded for doing the things you're normally supposed to do.

Beyond the basic level of functionality there's additional badges for people that sort of enjoy the site and want to actually get all the achievements — sort of the completionists — who actively participate in the site. And then there's the hard-core people, right, which would be me by definition 'cause I'm... I moderate on the site. But we try to get all the badges just because we can.

So it really supports I think several different methods of interacting with software and it's a really neat concept.  It's also very fun and playful.  Other people can view my gamer card and see what I'm good at and what I enjoy doing based on which badges I've chosen to get, or achievements.  So that's one way we're gonna encourage that, for people to come back.  But Joel, did you have any other...

[20:25]

Spolsky: Um — yes!  What were we talking about?  Oh, uh... yeah, I like the badges, I think people will co-operate just to, just because it's fun to be an expert, and to say, "Ooh, I know the answer to that!  I can, I can help some people!"  Uh, and I, and I think they will come back, kinda partially to establish themselves as an expert in a particular field.  Um, partially, uh, just 'cause it's, it's like, y'know, why do people play trivia games, 'cause it's fun to, to rattle off the answers and, and be right. But, I've also thought about what do I want to get out of StackOverflow personally?  One is obviously being able to ask, uh, and answer questions.  But I have certain expertise on things like, ah, the business of software.

Atwood: Well, also QuickBooks.

Spolsky: QuickBooks?  Oh yeah, that's right, QuickBooks XML.  I've forgotten everything I...

[garbling, laughter]

Spolsky: Forgot everything I ever knew about that.  But, uh, we wrote a, we've got a lot of QuickBooks integration code that I wrote.

Anyway, The business of software, what I was thinking of doing actually is just have a little tag called, "Biz of Software", or "Ask Joel", or both, maybe, "Ask Joel" and "Biz of Software".  And just maybe subscribe to an RSS feed for that tag, when new questions come in and if they're interesting, I'll go answer them and then I can [...] point people on my website to my answers on that topic.  Just in general.  So it's almost like my blog — kind of — like you could subscribe to see Joel answering questions about the business of software, you can ask me questions [...] I do this for the same reason as I create a website, as I create Joel on Software, 'cause I wanna kinda share the knowledge.

Atwood: Right, and I want to emphasize again how low friction our site is.  I think you will be very hard pressed to find another site that lets you participate with as few clicks as we do, and as few sort of logins — you don't actually need a login to participate which is...

Spolsky: And in fact, even if you have one, it doesn't work — as I'm discovering, in the beta.

Atwood: [chuckles] We do need to get Joel's login — just to give you an idea of where we are, I said, we're still in beta — Joel cannot log in.  We can log in, but we need to do a lot more...

Spolsky: It lets me in, it just never shows my name.

Atwood: I know.  Which defeats the whole point, because your reputation is tied to you.  So you're right to be, you know, concerned by that.  We will also have voting, I should have mentioned that, you're going to have your sort of semi-traditional voting system, so people can vote on the questions and the answers.  Those votes will transfer to your rating as a user, your "reputation score" is what we're calling it.  One thing that Jarrod did that I thought was very clever and that I totally agreed with, without even consulting him on it, is up-mods are twice as worthy as down-mods. So voting down doesn't hurt people very much whereas voting up helps them a lot.  So negative votes are sort of downgraded in our system — they still count, but not as much.

Spolsky: Hmm. [garbled] Yeah, very negative elsewhere [/garbled]

Atwood: Yeah, that always bothered me like on Reddit and places like that: one down vote complete cancels somebody else's up vote. And the problem with that, and I think we've talked about this a little bit before, not on the podcast, is when people down-mod there's a lot of reasons they'll downmod something.  One could be that they just don't like you, right? which is valid, I guess, but it doesn't really touch the topic that you happen to be talking about: because they don't... they just don't like you.  Or they just don't like the technology stack that you use, so they're going to down-mod everything you enter, because they don't like your choices in life — which is great, right?  So one way to combat that is to reduce the value of down-mods, to acknowledge that down-mods are kind of broad whereas an up-mod is pretty clear, it's like "I like what you're saying", right, well I guess you could have people that just up-mod everything you say because they're "yes men" or whatever, but thats — it would be really rare behavior...

Spolsky: So there's like, for a given post, you might find eight reasons to object to it, all which would cause you to down-mod, but only one reason to really like it, so a post on which people are really evenly divided would get eight down-mods and one up-mod, even though there's evenly...

Atwood: Right, I mean, I guess that's just my intuitive — I don't really have any science or data or anything...

Spolsky: The only thing that reminds me of is that, you know,  Paul Graham created Hacker News after the experience of Reddit, and he just doesn't have down-votes unless maybe I'm just not powerful enough to see them, but on the homepage there's only up-votes.  On the comments, there's up and down votes, on the home page it's just up votes, and he must have some kind of theory behind that.

[25:00]

Atwood: Some other things we are doing on StackOverflow that are pretty standard and we should also bring up the Joel test. I want to talk about the Joel test. I still like that. It's one of the my favourite things that you did. That was great. It's a classic, a classic.

Spolsky: Long before I jumped the shark.

Atwood: Back when Joel actually mattered. Let's talk about that. So, the Joel test and the other thing I like about the Joel test, not to get into promotion of your stuff (I have no reason to promote your stuff), but your job site. One thing I liked about your job site is  that it integrates with the Joel test, so when somebody posts a job listing, they'll  say, "Well here's this is the job we have, here's why it's awesome to work for us, and also we meet 10 out of 12 of the Joel test rules." These are great rules. I thought that was a very clever integration point; I really appreciated that. I've actually been going through the Joel test. It's something you naturally arrive at as a programmer, I think, when you work on a project. Another example of that is that we just hooked up CruiseControl , so as we check in code, it actually does a build for us, deploys it to the server, and sends us a summary email of here's the changes that went in, here's the build process. It does unit testing as well. There are some basic unit tests we run to make sure it's kind of working. I think that's  a very natural evolution and I guess that's Joel test #3 "Do you make daily builds?" It's a little beyond that actually, above and beyond, but certainly it meets the Joel test.

Spolsky: People have asked me over the years, "Why don't you add unit testing to the Joel test as the 13th requirement" that you do unit testing, or test driven development, or some form of test first or automated testing as part. The truth is that you have to go back and remember what the Joel test is. It's not a complete encyclopedia of all good practices. Nor is it the Ten Commandments. What it is, is a metric for the quality of a team that's pretty hard to fake and is a pretty good way to quickly decide whether a team is a good development team or not. It was originally designed to be a way for job applicants to look at a job. Originally, in the early days, I wrote that because a friend of mine came to me and said:

I was applying to a bunch of jobs and some of these companies look organized and some of them look disorganized and I found that a good way to find a good employer was to ask them during the interview to show me the last spec. If they looked at me like they didn't know what I was talking about, I didn't really want to work there.

Atwood: This was eight years ago, to give you the credit...

Spolsky: I probably wrote it eight years ago, but that particular incident was probably 10, 11, 12 years ago that somebody mentioned this. I thought about this and said, "hey, that's pretty clever" and I tried to think of some of the other things that you would want to check that your employer is doing to decide that this is a good place to work. I thought about how I took a job once because the interview was so difficult that I realized that I probably wouldn't be working with morons. Suddenly I realized I don't want to work at a place that doesn't make its programmers do some programming questions during the interview process. And so I came up with this list of twelve things which honestly if you are going on a job interview and are interviewing with several people in the course of the day and they all say at the end of the interview, "So, do you have any questions for me?" you can probably find out information about the Joel test in the first 3-4 interviews. You can get answers to all twelve of those questions. "So what do you use for source code control?" "Oh, we just carry floppy disks around the hallway." Ok, hmm, yeah, I want to work here.

Atwood: [chuckles]

Spolsky: So that's what it was designed for. Just because something is a good development practice doesn't mean it has to be on the Joel test. The other thing about unit testing and test-driven development is that it's really difficult to get right. There's all kinds of cases where it doesn't work, so there is a lot of controversy. It's not a universal thing. There are too many cases. There are cases like GUIs where you can't do it. Or, think about a really mature product that has been around for a long time and you have a million tests in your test-driven development suite, a million little unit tests. Now, every time you make the smallest change, if it affects 0.1% of those tests, now you have ten thousand tests to rewrite. Test driven development, unit testing is very, very valuable, very, very powerful, but also it's not a universal "everybody should have this on 100% on all things no matter what." If you do it that way you're probably not being 100% smart.

Atwood: The way I describe it, and this is something I stole from Fowler who had a quote on this, is that as a programmer you don't just write code and check it in, you write code, you run it in some way to exercise it unless you are pathologically bad.

Spolsky: Or pathologically good. [chuckles]

Atwood: Yeah, or you're that good, you're like a ninja who doesn't ever need to run the code you just check everything in. You're like Knuth or whatever.  Just taking that process, the manual ad-hoc testing that you do, think about "How could I don't [sic] repeat myself? How could I avoid having to do this next time I touch this code?"  Because the next time you touch this code, you're gonna have to do the same exact thing, right?  Well now I run it, I type some stuff in, I make sure it works.  So part of, I think, getting on the road towards testing — and I agree, it's a very, very long, hard road — is thinking: how you can avoid doing the same things over and over, e.g. manually testing your stuff every time you make a change to it.  So if you think about it more in terms of "take what you're already doing, manually, and just come up with some framework for doing that automatically", then I think you get the right mindset of what it's trying to accomplish.  It's not trying to create more work for you, necessarily, it's trying to reduce the amount of work you do in the longer term.  It does take a little bit more work to set up unit tests, but ultimately, say you make fifty changes in that code.  Well, that's fifty times you don't have to run the app, type some stuff in, press "Enter" and see what happens.  Does the unit test run?  Then, OK it works.  Of course then you have the issue of, OK, the unit tests may not be sufficient, they might not be testing some case that actually fails, so it does take some effort.  But that's the way I like to look at it, and that's something Fowler expressed, and I liked the way he said that.  So another thing that we do, that's kind of fun now, is we — one of the things that I struggle with on websites is, what version is a website?  Like, do you guys have a version number on FogBugz? 

Spolsky:  Yeah, there's four. [laughs]

Atwood:  Four?

Spolsky:  I think so.  I think there's the major version, which is 6, there's a minor version, which is 1, and it's gonna go up to 2, there's —

Atwood:  Is this on the page?

Spolsky:  Yeah, it's on the homepage, you click on the kiwi, it's at the bottom there.

Atwood:  Oh yeah, version 6.1.3 OH DB630 GEN1...  Wow, that's a lot of —

Spolsky:  Well, the database itself has a version number, which may or may not go up every time, that's basically like the file-format version number, effectively.  And there's some code that's like "Oh, you're using a database version 3, but we now have some new features, so we're gonna upgrade you to database version 4."  And that doesn't have to sync with releases that we release to customers.  And actually the QA team has recently demanded that we start producing build numbers as well, so there'll be a fourth number on there.

Atwood:  Yeah, so ours is a little simpler than that — for now — but we do sync up with the Subversion, I don't know what you call it, but like the check-in number, the number of this version database, like a three digit number now, until we check in more, I guess.  So at any given point, if you go to the website,

Spolsky:  Wait, but [garbled] file, right? So it's just —

Atwood:  No, it's just a total number of the current —

Spolsky:  Oh, right.

Atwood:  Basically, it's the number that represents getting latest at a current version.  They don't call it getting latest, they call it

Spolsky:  That makes sense, you could use that as the so-called build number, which is the lowest thing. 

Atwood: Yeah, but this is a great point too. When I worked on projects I certainly agree that the database getting out of sync with the code was one of the major sticking points. It was like well the database should be versioned, which it is in source control - we have it in source control so we're not repeating the particular failure mode - but it is good to keep a version, an explicit version number in the database so if something goes wrong and you deploy the latest code to you know 2 versions ago database, you don't just immediately blow up, maybe there is something that actually checks the number at start up.

Spolsky: Your situation is a little bit different than FogBugz because you guys will only ever be running against one database.

[pause]

Atwood: Well, true. Although once we get into the beta we'll have multiple databases on the same box 'cause we're in development has to go in parallel with the beta so there should be multiple databases running.

Spolsky: And then you start to run into problems like: I have a stored procedure in my database and takes three arguments and I want expanded to take four arguments. But I can't because the person calling the stored procedure in the code has to change at the same time as the database changes. Which can't happen in a production database. So you have to make a new version of the stored procedure that takes four arguments. You name it you know underscore two or something. And you start calling that from the new code, while the old code uses the old function, and it's kind of sickening but that's life.

Atwood: It's kind of ghetto, but I think even the Windows API does that. Don't they have like .ex methods?

Spolsky: Yeah. And then they call it ex, and then ex2.

Atwood: Yeah ... [chuckles] ... and then they add numbers too it. Yeah, that's a tough problem, I don't know how I would solve that. So ... probably on StackOverflow the next thing to talk about is ah ... gosh ... there's been a lot going on this week.

Spolsky: Yeah ... uh really? Cool.

[pause]

Atwood: [chuckles] Sorry, I have some notes here, I just lost track of what I was going to talk about. Let's move on to something totally different.

Spolsky: Okay, let's take a question. Unless you have have something different on your list. You sounded like you have something different on a list there. 

Atwood: I do, but we can come back to it.

Spolsky: Alright. Oh, come on give me your question, it's probably better than... 

Atwood: Well, it's not really a question. I was just going to talk about Petzold book on Turing.

Spolsky: Oh, Petzold’s book on Turing, I have not read that.

Atwood: Yeah, so Turing's famous paper on computability is essentially the basis for all modern computers. He basically invented computers - all modern computers - in like 1936 with this one paper.  There's some other work going on from people that sort of got similar results, but Turning's the one that generally gets most of the credit for this paper.  So Petzold spent nine years writing this book.

Spolsky: [giggles] Well, he did other things too during that time.

Atwood: Well, yeah, of course. But it was a long term project for him. And it's amazing – he posted on his blog all the research he'd done last nine years. He posted a picture of his bookshelf, all the books he had used to research the Turing stuff, to get the background. Because he talks about the history, you know, pretty much every aspect of the paper is examined, all the context, all the related topics are spidered down into as well. And it has, like, five bookshelves worth of books [six bookshelves, but not bookcases]. Like, literally. It's like: “Ok, here's my bookshelf.” It's unbelievable. It's clearly nine years worth of books, that he's been reading on a topic. It's very exhaustive. But what I like about the book, and not to pimp the book too much, but I just really enjoyed it, because I love history. Like, he's writing about people, more than code. Or really both things at once. Because he's examining Turing in the context of the mid-thirties, all the research that was on. And then, the other things that Turing did. Because Turing was one of the main guys who solved the Enigma encryption problem in World War II. So he examines that. And then Turing actually... I don't know, how much do you know about Turing and history and what actually happened to him? That, actually, kind of sad...

Spolsky: I do know, because there was a great play. What was that play called? “...of the Enigma...” something? Here let's ask the Google... “Breaking the Code”. Is that it? “Breaking the Code”? Was that a play?

Atwood: Yes. That sounds right.

Spolsky: Oh, yeah. I mean, there was a Broadway play. A theater play. About his life.

Atwood: Right. And you saw this one?

Spolsky: I did!

Atwood: In New York city, perhaps?

Spolsky: In London.

Atwood: In London? Wow, really impressive.

Spolsky: Maybe it was in New York...

Atwood: Oh... Yeah, so it's a little bit of a sad story. It's like one of those... Oh well, I'm a pop-culture maven. I'm gonna turn this into a pop-culture reference, those “Behind the Music” things, where they cover bands that become very successful. They always has a dark side, because success, kind of, ruins you on some level. Like, you have access to all this really bad things, all this negative people and you have all this money. I'm not saying that's happened to Turing, but it's like that Turing is one of the brilliant minds in the computer science. I mean, he is called literally “the father of computer science” for that reason. And he's a guy who was completely persecuted to the point that he killed himself because he was gay in the late fifties. And it really pains me to even read about that. I mean, he's a guy who basically beat the Nazis. Right?

Spolsky: Yeah.

Atwood: Even in his time I'm sure he was viewed as a major... like an Einstein-like mind in the field of computing. And that didn't seems to matter, he was prosecuted like just a common hooligan. And it's just sad the way his life ended. He actually ate a cyanide-dipped apple. So overtones of, I guess Snow White or the bible or whatever you wanna read into it.

Spolsky: Yeah. Socrates.

Atwood: Yeah, Socrates! Thank you. And Newton. The apple is very...

Spolsky: There is a made-for-TV movie of the play I see here, you can see. I wonder if the made it a DVD or something.

Atwood: But I'm just flipping to the... I love this book. I complained and I felt bad, I don't know if you saw, but I railed on Petzold's other book, which is on Windows — WPF book.

Spolsky: Oh, you didn't like it?

Atwood: I really gave that a very negative review, because I felt it was the “wall of text” problem. And the sad thing is that Petzold is such a brilliant writer. I mean, when he's writing about history. I mean, he really makes it come alive. All this background, all the history, all the reasons this stuff that matters.

Spolsky: This book is on win32 programming or Windows programming in general. The original “Programming Windows” was one of the best written, clearest written books I've ever read about programming.

Atwood: Well, I think that's my point. Is that Petzold is such a good writer that he's wasting himself on really narrow technical topics. Something like this, which lies at the intersection of the people, history and computing. It's a really meaty topic with a lot of stuff you can talk about to explain it. It's not like the latest API du jour.

[40:08]

Spolsky: I think he recognizes this.  I kind of feeling that one of the reasons he's writing these books about Turing is because the WPF book was, you know, not a huge seller and you can no longer make a living writing books about programming Windows.

Atwood: Well that's funny than, because I am not sure a book about Turing going to be like...

Spolsky: Well it's gonna have a mainstream audience.  Surely the New York review of books or what ever will review it and he'll get a ...

Atwood: Perhaps but still pretty... It's still pretty dense but it - I think the kind of book 10 or 20 years from now will still be totally, totally relevant and I think that's great because Petzold is such a good writer that he really deserves books that have longevity that people will come back to.  So I was really just excited for Charles when I read the book.  I really enjoyed it too, so I recomend it.  Everyone listening defiantly get a copy of "The Anotated Turing".  If you have any interest at all.

[40:59]

Spolsky: Ok. The Annotated Turing, by Charles Petzold, available from your favorite bookstore. This'll sell to a general history of science audience.

Atwood: Sure. Sure, I think it will.

Spolsky: More than a programming book. A programming book that sells 10,000 copies is a bestseller. That's just pathetic. 

Atwood: Yeah. No, don't write books. I had a whole long email chain with someone who wanted to write a book, and I was really trying to talk him out of it. I don't know. Do you have any words on that? You've written some programming —

Spolsky: I have, but —

Atwood: Your books are —

Spolsky:  Y'know what, I have a new book that just came out, it's called More Joel on Software.  It's the further —

Atwood:  Oh, you do?

Spolsky:  Uh huh.  About a week ago, yeah.  It's a bunch of articles from Joel on Software — it's sort of a continuation, combined with Joel on Software (the book).  If you combine those two, you have pretty much all the good stuff from Joel on Software.  There's nothing new in the book, and I should make that clear.  If you've been following along, if you've been reading my blog since the beginning of time, you've read all this stuff.  But it's a lot of material, and having it in a book form is a great way to read it for the first time, or give it to somebody.  Or put it on your shelf.  

Atwood:  Do you think that your blog turns well into a book?  Because I've been approached for that, and I've always pooh-poohed it, because I think my blog in particular, does not translate well to that format.  I think yours might.  But what do you do for chapters, how do you organize it?  Do you just group by topic?

Spolsky:  Well, there's sections by topic, yeah.  So there's a bit of a theme, but it really is like reading a collection of essays, and not like reading a single book.  But then again, y'know what?  It's a book, a bunch of chapters.

Atwood:  You mentioned we had some more calls to go to?

Spolsky:  Good question.  Let's take a call.  Here's one, from Nicholas:

Nick Kavadias:  Hi, Jeff and Joel, my name's Nick, and I'm from Sydney, Australia.  My question is, do you have any advice to someone who wants to get involved in a tech startup that's not in Silicon Valley?  I get the feeling from Paul Graham's essays that you need to be in Silicon Valley because it's a startup hub.  Thanks guys, and keep the podcasts coming!

Spolsky:  So Silicon Valley startup hub — I personally think that the negatives of Silicon Valley outweigh the positives.  

Atwood:  But you live in New York City, so you're biased.

Spolsky:  True.  That's true.  Y'know when I see the kind of crap that comes out of Silicon Valley— I mean seriously, just look at TechCrunch, and read about all the startups, and it's all the same thing, and there's just a groupthink going on there, and the people are just piling onto social networking, with every possible variation of social networking, and it's all so unoriginal.  And there's something about the groupthink that happens in Silicon Valley that I think makes it really, really difficult to stand out and succeed.  And the minute that you start to fall a little bit behind, all your good employees flee to the next big, exciting startup, because there's always something more exciting over the next road, or in the same building, or down the street.

Atwood:  So I think, to me, the question is about— it's about locality and teamwork.  So I think now, with the Internet being so mature, it's possible for people to work remotely.  I mean, look at my team.  So I have a guy in Corvallis, Oregon, I have a guy in Morganton, North Carolina, and then I have me and you, and we have a virtual team, right?  We're four different people, and four different dots on the globe.  Well, all in the US, technically.  But timezones can be a challenge, I will say that.  And I've heard that many many times before.  When you have many timezones separating you from your co-workers, you just get on very different cycles, and it can be painful to work together.  And I think there's also something to be said for physical presence.  I mentioned when Jarrod was here visiting from California, it was really fun for me to work next to him.  And I also noticed when Geoff and Jarrod were essentially on vacation for a little while, I was working sort of alone on the code, and I felt very isolated.  It was weird to not have anybody to type, like, instant messages to to ask questions, or send an email and get a quick response back.  And working in isolation kinda sucks too.  So I think what you gotta balance there is, how much do you value physical presence versus, the virtual working world of being on Skype, and instant messaging and things like that.  Now Joel, you probably don't have any remote employees at Fog Creek, right?  Everybody works in your office.

Spolsky:  Yeah, it's just banned.  We will never do it.

Atwood:  Right, and the place I worked before, that was the model.  And there's a lot to be said for that, because you get a really nice team dynamic.  I mean, don't underestimate the power of physical presence.  It really does help you write — I think — better code to have people that you can talk to and go to and just have [garbled] lunch.

Spolsky:  But wait — this is all very interesting, but this wasn't the guy's question exactly, which is, can you do it from Sydney, for example?  

Atwood:  OK, so maybe I interpreted the question a certain way.

Spolsky:  Certainly, can you be virtual or not virtual is an interesting question, and we can sort of debate — but that's not exactly what he was asking, he was asking "Do you have to be in a tech hub to make a startup successful?"

Atwood:  Oh, like he was founding a startup.

Spolsky:  I think so.  Wasn't that his [question]?

Atwood:  Maybe I misinterpreted the question, I apologize.

Spolsky:  [kidding] Let's play it again! No, let's not.  Lemme just answer that one though.  That's why I was saying, my feeling is, we're in New York, and I feel like we've benefited and lost, and the benefits have outweighed the losses.  And the biggest two benefits that we see directly is: a lack of groupthink, so you're more likely to do something original and different, instead of just making pet food like every else is - pet food on the Internet; and secondly: the lack of competition for the good engineers which is not true everywhere but that really means if your place has a high percentage of engineers or programmers or highly technical people or creative people — maybe Melbourne, more than Sydney, in Australia — relative to the number of startups where they can work you'll have an easier time recruiting, and maintaining, and keeping people around.  And that's the most crucial part.  That said, I should mention that I have never known an Australian company to succeed without an outpost in the United States, to at least do sales in the right time zones.  And it's usually one of the first things that they do, is figure out how to get set up in the States, and get those Qantas Frequent Flyer miles.  Because it is very hard not — and the same thing holds for  Israeli startups, many which I'm familiar with.  And all of them probably set up their US office literally on the first day that they get set up.  That said, there's not as much of an angel or a VC community in places like Australia — although there's some, it's relatively weak compared with California — but then, there's not as much competition.

Atwood: Right then. That was good we gave you two dimensions to your question. Mine was like "do you want to work for a startup?" and Joel's was more like "are you founding a startup?". Sorry I didn't mean to interpret it in the wrong way. But hey — two for the price of one.

Spolsky: Hey maybe you had it right.

Atwood: [Laughs]

Spolsky: [Garbled] I think the advice is what to do if you're not in a place like Silicon Valley — is this gonna hurt — you know there are certain places where you see a lot of startups coming from.  My... you know our biggest competition in the bug tracking market is a Sydney-based company so that they were certainly successful starting there... and... obviously outside the United States; there are places like Israel.  Skype came from Europe — came from the Netherlands — and a lot of programmers from Estonia and let's see, there are some pretty big companies that came from Czechoslovakia, not from France so much or England — I don't know why — but yeah actually England, there's a lot of UK-based companies that have done great things. So yes, it's definitely — it's possible to be be anywhere — Eric Sink will tell you that it's great being in Champaign, Illinois — little farm town in the middle of nowhere and there are pros and cons.

Atwood: Certainly. Do we have another question?

Spolsky: Yeah, why not. This is taking us back a couple weeks ago.  We were talking about Silverlight, as you remember, and I believe that what we both said is that Silverlight is...

Atwood: Like Flash, but...

Spolsky: Yeah. As long as the model is a rectangle embedded in a web page that's it's own little sandbox - it's gonna go the way of Java and Flash which is, you know, useful for some things but not truly in the... of the grain of the web. That's kinda...

Atwood: Wait Joel — how about a rounded [...] rectangle?

Spolsky: [Laughs] Heck - if you could round it, well that changes everything!

Atwood: Yeah, that's a whole different thing.

Spolsky: Whole different world, yeah...

Stephen Bohlen: Hey guys this is Steve Bohlen calling from New York City, just wanted to let you know I'm really enjoying the podcast hope you keep it up. Joel, I think in Episode 11 you spent a considerable amount of time talking about problems with Silverlight adoption (and ultimately Flash adoption as well), being that it kind of breaks a lot of the web navigation paradigm, in that you can't copy URLs out of the browsers address [bar] and ultimately the [broken] back button kinda destroys the user experience. I was curious how you reconcile some of those statements with a lot of the things that are going on in AJAX enabled websites. It seems to me an awful lot of the same criticisms can ultimately be leveled at AJAX enabled websites as well. You can visit the site and spend a lot of time on it and not once does the URL in the address bar change. In a lot of cases hitting the back button obviously destroys your navigation as well. I was curious if you could talk a little but about how you reconcile those two things when AJAX adoption seems to be a positive but something like Flash or Silverlight are typically frowned upon as being against the grain. I want to thank you guys again for the podcast I look forward to it every week. Thanks.

Spolsky: Thanks. Okay. So that's a question that I think you almost answered yourself there Stephen, which is "Silverlight vs. AJAX: Does it break the web?". Obviously AJAX is not all good and Silverlight is not all bad. There's no conflict in saying that some aspects of AJAX can be bad and it depends on how you use AJAX. There are basically two approaches to building an AJAX applications that people have taken.

One approach, we'll call it the Gmail approach, is the pure Javascript approach; which is that once you get on a page everything is going to be generated by Javascript and all the interaction and everything that happens on the page are going to be entirely within Javascript. There's no history and the browser is not really involved at all.

Then there's the hybrid approach; you're still using HTML for most of the navigation - when somebody clicks on an email message, for example, that would navigate to a page that showed that email message. The AJAX is just there to speed up certain interactions within the page. If you ever do something with AJAX that appears to be a navigation, then you use one of many well documented tricks to convince the browser that the history should behave in a certain way so that you can go back. The back button will still work in the way that is expected. That's the approach FogBugz takes. When you use FogBugz it really does feel like HTML navigation but then there's just the rich, rich, rich world with all kinds of AJAX everywhere that makes things fast and spiffy.

You can do the broken navigation the AJAX way or you can, if you're doing AJAX you don't have to, you can use the Hybrid model which is more of a classic web navigation with URLs that are meaningful and AJAX to enhance the pages that you are on. That said, there is nothing wrong with the Gmail model. There is nothing wrong with building an application and making it a website. If your application just does a bunch of stuff and doesn't even have a concept of navigation or moving amongst different pages of content then you may be fine building something in a pure AJAX-y way. For example, if it's a stock trading application that's going to show level two quotes with little quotes showing up, stock prices you can click on and do things like trade and all that kind of stuff. I don't know if I would want "back" [button] to work in that situation. It's not really a classic web content situation.

If you're doing something where you're displaying content on a bunch of pages and navigating between them - something like news or mail, something that is navigation orientated - I feel like that should be done the HTML way.

Atwood: I agree with all that. I think a lot of what you said could be summed up as the theory of progressive enhancement. You start with something that is HTML, like a form for example, and then you can add an auto-complete box — that's an AJAX thing, it's a "nice to have" — it doesn't break the form if when you type it doesn't auto-suggest, but it sure is nice. Like in an email program, for example like Gmail, when you type it auto-completes email addresses which is hugely convenient but I could still do it manually if I had that off.