The StackOverflow Podcast

[incomplete]

Intro, advertising

[01:22]

Atwood: We thought the worst case scenario was that we would literally branch the code.

Spolsky: Sure.

Atwood: So then we would have two things to migrate bugfixes to all the time. And one thing - I know you guys use Mercurial, right ?

Spolsky: Yeah, and that would make it a little easier, but I mean it shouldn't really be necessary to branch the code.

Atwood: No, it shouldn't be, but one thing we found was that we did do a branch when we did the big database migration because that was such a big change, we had to have bugfixes go on the main line while we were working on the database change.

Spolsky: Right.

Atwood: Because all the fields change and all the stuff and we did a bunch of refactoring on the database.

Spolsky: Yep.

Atwood: And what we found was merging that in was excruciating - it was so painful. We actually updated to the latest version of Subversion, which is 1.6 I think? And it has "better" support for merging, and it was still just brutal - we missed so many things - there were at least, I want to say, five to ten things that we missed in the merge somehow.

Spolsky: So this is why everybody is abandoning those version control systems that are of the Subversion generation and they're moving to Mercurial and Git, and, to a lesser extent, the other distributed systems. There's something that took me a while to understand about Mercurial, but fundamentally Mercurial is - Mercurial thinks of the world as a list of changes, and Subversion thinks of the world as a list of different versions of all your files. And so for Subversion to figure out where you are on a branch to do the merge, all it can do really is do a diff and say "well, I don't know what happened, but the following things - we're different from you guys in the following ways", whereas Mercurial has this sort of added info of all the steps that were taken and all the transformations that were done, so it basically has more information to use in the merge and making the merge successful.

Atwood: Yeah. I think that's the key phrase, is that it feels like Subversion does so little to make your merge successful that the success of the merge relies entirely on you doing every stinking little thing correctly, and if you miss anything then you get a bad merge, and the thing that sucks is that you don't figure out until a week later that this bugfix that you put in is not in the codebase.

Spolsky: Yeah, because it might compile.

Atwood: It pissed me off - every time I ran into I just got very very angry because I felt like my tooling had failed me.

Spolsky: Well I would highly recommend just switching to Mercurial, also because you guys are all a distributed team, right? Like the three of you are all in different places, and we're going to want to have the hosted version that FogCreek is doing and it would be really good, even if we have to fork the code, for us both to be using Mercurial, because then we could still throw each other bugfixes, even if we forked, you know, years later we can be throwing each other bugfixes.

Atwood: Are you like announcing that now on the podcast ?

Spolsky: I guess I might as well, what the heck, I've waited - we have no secrets. We haven't even hired somebody to develop this thing yet; Hey, if you are a StackOverflow listener and you're a really good developer, and you're pretty good, especially - we'll hire you even if you don't necessarily know ASP.NET, and ASP.NET MVC, but if you do that's a big help, and you want to work on Stack Overflow, then we've got an opening here at FogCreek, so email your resume to jobs@fogcreek.com.

Atwood: But you have to be local, right ?

Spolsky: Nope, we'll hire - you just have to be, you just have to have permanent right to work in the United States, so that means that you already have permanent residency like a green card or US or Canadian citizen. A US or Canadian or Mexican citizen with a Bachelor's in Engineering. I don't know, it's complicated; basically, no H1B's, because you just can't get them anymore.

Atwood: Why don't you, OK, well that's cool, that's awesome that you're opening it up to the whole United States.

Spolsky: We always do, about half the people we hire we wind up moving to New York, more and more actually, I can't even think of any local New Yorkers that we've hired.

Atwood: OK, cool, so there's a relocation sort of thing there ?

Spolsky: Yeah, you'd get the whole package: FogCreek stock, the relocation package, the free lunches, the uh, anyway.

Atwood: Cool. Well that's exciting, because I'll tell you my mailbox I don't want to say overflowing, but every few days I get an email from somebody that wants, would like to use the Stack Overflow engine in some way, and I just don't really have a good answer for them, so this is exciting for me because now I have at least a reasonable answer for them, which is that we're working on a hosted version of it that's going to be run on the FogCreek infrastructure.

Spolsky: Some hypothetical person that we really want to hire hopefully will hear this podcast and send me a resume.

Atwood: The funny thing about that is that we're very excited about that and we feel that it fills a real need. It's a service that you guys already do very well - it's a good fit on every possible level, but the thing that makes us all pause on the team is that other people are going to look at our code and we're like "ooh, is our code really good enough for another developer to come in and not tear their hair out?" I mean, we're probably being oversensitive, but, I think that's the reaction I have with all my code - is it good enough for other people to work on? Maybe you should spend a month refactoring it first.

Spolsky: Well, I think everybody feels that way, and that is actually true that there is - there's kind of two levels of code: there's the level where it runs and it's debugged and you're kinda happy with it and you can continue to work on it if you need to. Let's say there's three levels, that's the middle level. The bad level is you know it's bad and it's a pain to work on and any time you want to change something you know you're going to be pulling out your own hair, and then the top level is like you could publish this in a book because after you got it working you went over it and refactored it seventeen times and cleaned it up and did all kinds of extra work that didn't get you any extra functionality, but did make it code that anybody could dive into, so maybe you've renamed things, you've cleaned things up, you've reorganized things several times, you've gone through the code trying to make it like literary code where the comments just smoothly, seamlessly flow with the code so you can figure out what's going on.

Atwood: Our challenge, too, is that we started in one of the betas of ASP.NET MVC and we sort of learned, not that MVC is super-complicated, but we learned MVC as we were going.

Spolsky: That happens so often.

Atwood: And then there's points in the code where we did things that I don't think really - they're not wrong, they're not horrible, I don't think anything in our code would make you question our core competency as software developers, I will say that, because there's always The Daily WTF code where these people shouldn't even be near a computer, much less writing code. I don't think we're at that level, but there's definitely parts where we did things that aren't in the spirit of MVC because we didn't really understand or, honestly, some of the pieces of MVC weren't there when we started. All we had was the root pieces of it and they sort of built up pieces around it. For example, validation - there was no real form validation framework so you had to sort of roll your own, and that's essentially what we did we rolled our own validation. If you were starting out now there's no way you would do that, but we have all this existing code that we have to support.

Spolsky: So there's no reason to change to their new, modern, official form validation.

Atwood: I'm a big fan of refactoring, believe me, and when I started I told Jarrod, one of the first things I told him was "look, we're going to rewrite this app three times, just top to bottom", that's just the way software works.

Spolsky: You mean you're going to start from scratch ?

Atwood: Well not literally, I was being a little dramatic for effect, my point is that you want to refactor all the time, that's part of having healthy codebases, you go in and you just tear things up that aren't good and make them good, right? Even if you don't - it's a question of balancing resources, you don't do it all the time, but you periodically tear.

Spolsky: You take a piece and tear it out, or you can take a piece and just try to clean it up.

Atwood: Exactly, you don't just say "OK, I'm going to fix this" - it's kind of like working with legacy code, you're like "oh, I'm going to touch this as little as possible, just to get it to do this one thing that I want then I'm not going to, I don't want to break it". I don't want to have that attitude, that walking on eggshells attitude towards code because I feel like that's unhealthy. At that point you have a legacy codebase and you're not really alive as a project in my opinion, so whenever we do stuff I encourage the guys to - and they do it all the time - to go in and just rewrite things, little things, that are not the way they should be to make them more elegant or just not melt-your-brain when you look at them. So I'm for that, but on the other hand, it is true, and we do this all the time, we regress. Every time you touch code, every time you change something, the odds of you breaking stuff are, you know, really high.

Spolsky: So that is what the trendy boys would call a "code smell".

Atwood: Yes, yes, yes. And then of course you could that's what TDD is all about, right? Theoretically it's like getting a whole set of unit tests in place so every time you change something, you know, you're protected, you know that nothing's going to break.

Spolsky: And I thought the theory, I mean it sounds like the theory behind some of the SOLID principles, which we like to butcher on our show, had something to do with making sure your code is in a place where every time you change something you don't break all kinds of other, unrelated things, because if you follow these principles presumably every time you want to change something there's, you know, one elegant file that you just have to find it and go in there and change a zero to a one and everything has been thought out for you already and so it magically happens without any bugs.

Atwood: Right, and before people, and true, we could, we do have some unit tests, we could have more unit tests, but I find too that some of the regressions you get I don't know how in the world you would have a unit test that would catch them, like the other day I went in and I normalized one of our CSS classes that had to do with the OpenID field, the way it displays, and made it the same across, we were using different things in different places which didn't make sense, so I normalized it. This actually broke some of the JavaScript on the client in a very minor way, nothing horrible, but the login page JavaScript does some sort of stuff to help you figure out what OpenID provider you're using.

Spolsky: I was having trouble logging in.

Atwood: Yeah, well we did some login refactoring and broke a few things, nothing serious, but minor, annoying things. This was one of them.

Spolsky: Was it, wait, tell me Jeff real quick because maybe this is another bug that I need to file, like I was clicking on the little MyOpenID thing and I was typing my name and I was clicking in some other place and it was just failing to make it look like I was logged in but if I'd actually, like it was telling me "no, that's, you're wrong, you cannot log in", but actually if I went back to the site then I was logged in, is that that bug ?

[11:48]

....

 

[17:16]

Spolsky: That's cool, and you know we were talking earlier - I wanted to mention something that occured to me - we were talking about how you guys were learning ASP.NET and MVC as you went along, and I can't remember a time when I wasn't building a new application in an environment that I did not have any experience with; whether it was a programming language or the frameworks, it seems like you're always learning as you go along for some reason. You never really get to build a new application in a framework that you know really well.

 

 [18:47]

Spolsky: C++ is enough rope to hang yourself, and then a couple of extra miles of rope, and then a couple of suicide pills that are disguised as M&Ms...

Atwood: <laughing> Disguised as vitamins

Spolsky: <laughing> Peanut M&Ms, and you know, and the occasional electric knife and so forth.

[19:05]

...

[63:58 ends]

Outro, advertising

[65:15]