Podcast 063Revision #5, 8/5/2009 11:57 PM71.192.163.79: "Start of actual podcast [01:10] - [01:40]" Tags: (None) Previous Next |
Podcast 063Revision #7, 8/6/2009 1:17 AM71.192.163.79: "Adding up to [05:02]" Tags: (None) Previous |
---|---|
Atwood: This is Jeff. Spolsky: Uh huh. <Food chewing noises> Well who else would it be? I called Jeff. Atwood: Why are you eating lunch? It's like... 4:00 P.M. there Spolsky: I'm sorry. I noticed that, umm, in the little chat window in Skype they have throwing up. I'll send you that. Blehh. Atwood: Yeah. Spolsky: But they don't have eating. Atwood: You'd wonder if eventually there'd be some standardization on emoticons, right? Like every device would have a standard set of these things. Spolsky: There's probably an IEEE standard. Atwood: Yeah. It's certainly a candidate for it anyway. [01:40] [28:17] Spolsky: ...almost everybody I know is not yet using Google Chrome 'cause they're waiting for AdBlock. Like they just need to be able to write a plugin for Chrome that can block ads. Ahh and as soon as that... or... and, and, and that's the most popular plugin but there are a lot of other smaller plugins that people are relying on in Firefox and they won't switch to Chrome or switch back to IE or certainly not Safari or Opera because those plugins aren't there on that, on that other platform. Atwood: Oh, the lock-in. Sure that's... Spolsky: Yep. Atwood: ...a great example. Spolsky: So, the classic example I'll give was the first thing in my career was that Lotus 1-2-3 had Lotus macros and Lotus macros the way they worked was you went into a cell and you just entered a bunch of letters from your keyboard, you know, like /C, M or whatever. And then ahh... and then you could tell it to run that cell and what it would do is actually generate those keystrokes that you had typed into that cell. Umm, and so... umm, you could thus automate Lotus 1-2-3 in certain rudimentary ways. And people started writing these and they got very, very sophisticated and they had these very,very complicated spreadsheets that had lots and lots of crap in the cells. Umm, that was macros that they depended upon to run their business and when they were trying to convert to Excel, you know, all the data in the spreadsheet opened fine and the actual calculations were fine but for the longest time it couldn't run those macros. And so people would not convert from Lotus to Excel. So what, what the Excel team eventually had to do was build a complete emulator of Lotus 1-2-3 that emulated the complete Lotus 1-2-3 user interface. Umm, so for a long time in Excel - it's not turned on now - but if you hit / a Lotus menu would pop up. And er, it would have all the same things that Lotus 1-2-3 had in it. Umm, and that's still there behind the scenes - you just have to sort of enable it. And, umm, that took an enormous amount of work. So if you've got a, a product, and you make a plug-in API... or some kind of an add-in API of some sort or a macro language... ahh, the burden then... and then you actually get people to depend on these plugins then anybody that wants to displace you is going to have to reproduce all the behaviour of your API perfectly. Which can be very, very, very hard, right? In the case of Excel, it's never been done, right? There's a huge surface area to that API. [30:31] --- Atwood: edit me! Spolsky: I have a request of our listeners if you're listening to this show. We're trying to organize these stack overflow dev days and I've found alot of good speakers on alot of good topics but what I really want is some Python speakers. People to do a python tutorial in each of the ten cities and I don't have any Python speakers lined up at all and I don't really know who the good Python teachers and Python tutors are. So if you've ever gotten a Python tutorial in person or you've heard somebody speaking on Python who you thought was absolutely brilliant and fun to listen to and taught you alot in an hour. Which is what we want to happen at the stack overflow dev days. Could you please tell me who they are? and what their name is and even where they live? and do that by emailing that to devdays@stackoverflow.com which is our standard dev days address for any kind of dev days question about dev days. | Atwood: This is Jeff. Spolsky: Uh huh. <Food chewing noises> Well who else would it be? I called Jeff. Atwood: Why are you eating lunch? It's like... 4:00 P.M. there Spolsky: I'm sorry. I noticed that, umm, in the little chat window in Skype they have throwing up. I'll send you that. Blehh. Atwood: Yeah. Spolsky: But they don't have eating. Atwood: You'd wonder if eventually there'd be some standardization on emoticons, right? Like every device would have a standard set of these things. Spolsky: There's probably an IEEE standard. Atwood: Yeah. It's certainly a candidate for it anyway. Spolsky: Well this is podcast 63. Zero-six-three. Atwood: Mmmhmm. Spolsky: Do you get the problem where you plug in your iPhone and it says, uhm, the iPhone you plugged in ... Atwood: What.. what... what is going on over there? Splosky: ... <laughing> cannot be recognized, please unplug it and... Atwood: Is there like a car full of clowns going in circles over there or something? Spolsky: ... <laughing> plug it in again. Atwood: I mean what is going on? Spolsky: <Sigh followed by laughing mixed with incoherent sputtering> ahh, this is gonna be a great podcast. Atwood: You have not been the same since FogBugz 7 was released, there was something in that product that... that is not right. Spolsky: Well FogBugz 7 is awesome. Atwood: Mmmhmm. Spolsky: Uhm, theres another product here that the interns have been building along with 3 experienced software developers from the Fog Creek team as their mentors. And also co-programmers basically, so it's like a programming team of 9. Atwood: Wow, that's a big team. Spolsky: Plus two testers and two program managers. Atwood: Holy cow. Spolsky: So it's really more like 13 people on that team, yeah, which is the largest team we have ever fielded. And uhh... and you know how they always say, like, you can't schedule software uhh... if you try to just double the number of people and halve the amount of time that you spend doing things it's like trying to get 9 pregnant women to make one baby in one month? Atwood: Yes. Spolsky: You know that... that funny little expression? Atwood: Absolutely. Spolsky: Well, it turns out that with software that's not completely true. <Laughing> Atwood: <Laughing> Are you debunking another important myth on our podcast, is that what you're doing Joel? Spolsky: I.. I might just have to because you know the limitation that we face with summer interns is they only got 10 weeks. Atwood: Yeah. Spolsky: And even that is kind of a stretch because there's a couple of stupid colleges that give people their vacation later than everybody else? Atwood: Mmmhmm. Spolsky: And some not so stupid colleges, so actually, in our case it's the University of Chicago and Stanford. Both let people out really late and meanwhile the other people have to go back to school kind of early. So you only wind up with 10 usable weeks during the summer to build a product, if you're going to try to build it with interns. Atwood: Right. Spolsky: Uhh, so we just, you know, we split up the work and we had very, very detailed specs and we figured out what everybody was going to do in advance. And we're not going to really finish it this summer but we will have a feature complete beta by the end of the summer. Atwood: Cool. So throwing a bunch of people... so there's... there's... My challenge... Well, okay. I probably shouldn't be speaking about having large teams because my whole philosophy is predicated on having really small teams as I can possibly get away with... Spolsky: Yeah. Atwood: ... and keeping them small. But I guess as long as you have, you know, work for everybody to do and they're not stepping on each other. I mean that was always the big problem... you know, The Mythical Man-Month problem, was that people just start to interfere with each other... Spolsky: Mmmhmm. Atwood: ...they're blocking each other. There are communication breakdowns. There's all these reasons... Spolsky: Yep. Atwood: ... that stuff doesn't scale. So I guess if you have some kind of parallelizable... Spolsky: Right. Atwood: ... workflow where people aren't stepping on each other and they all have stuff to do and they can just work somewhat independently, I guess you're right. That could really... that could work. Spolsky: Well the real argument that The Mythical Man-Month makes is actually a little bit weaker than the argument that everybody remembers. Everybody remembers, "Ohh you can't just put a lot of people on a team." But, uhh, what the Mythical Man Month actually says is a slightly narrower claim. It says, "If a project is late, adding more people makes it later." Atwood: I see. [05:02] [28:17] Spolsky: ...almost everybody I know is not yet using Google Chrome 'cause they're waiting for AdBlock. Like they just need to be able to write a plugin for Chrome that can block ads. Ahh and as soon as that... or... and, and, and that's the most popular plugin but there are a lot of other smaller plugins that people are relying on in Firefox and they won't switch to Chrome or switch back to IE or certainly not Safari or Opera because those plugins aren't there on that, on that other platform. Atwood: Oh, the lock-in. Sure that's... Spolsky: Yep. Atwood: ...a great example. Spolsky: So, the classic example I'll give was the first thing in my career was that Lotus 1-2-3 had Lotus macros and Lotus macros the way they worked was you went into a cell and you just entered a bunch of letters from your keyboard, you know, like /C, M or whatever. And then ahh... and then you could tell it to run that cell and what it would do is actually generate those keystrokes that you had typed into that cell. Umm, and so... umm, you could thus automate Lotus 1-2-3 in certain rudimentary ways. And people started writing these and they got very, very sophisticated and they had these very,very complicated spreadsheets that had lots and lots of crap in the cells. Umm, that was macros that they depended upon to run their business and when they were trying to convert to Excel, you know, all the data in the spreadsheet opened fine and the actual calculations were fine but for the longest time it couldn't run those macros. And so people would not convert from Lotus to Excel. So what, what the Excel team eventually had to do was build a complete emulator of Lotus 1-2-3 that emulated the complete Lotus 1-2-3 user interface. Umm, so for a long time in Excel - it's not turned on now - but if you hit / a Lotus menu would pop up. And er, it would have all the same things that Lotus 1-2-3 had in it. Umm, and that's still there behind the scenes - you just have to sort of enable it. And, umm, that took an enormous amount of work. So if you've got a, a product, and you make a plug-in API... or some kind of an add-in API of some sort or a macro language... ahh, the burden then... and then you actually get people to depend on these plugins then anybody that wants to displace you is going to have to reproduce all the behaviour of your API perfectly. Which can be very, very, very hard, right? In the case of Excel, it's never been done, right? There's a huge surface area to that API. [30:31] --- Atwood: edit me! Spolsky: I have a request of our listeners if you're listening to this show. We're trying to organize these stack overflow dev days and I've found alot of good speakers on alot of good topics but what I really want is some Python speakers. People to do a python tutorial in each of the ten cities and I don't have any Python speakers lined up at all and I don't really know who the good Python teachers and Python tutors are. So if you've ever gotten a Python tutorial in person or you've heard somebody speaking on Python who you thought was absolutely brilliant and fun to listen to and taught you alot in an hour. Which is what we want to happen at the stack overflow dev days. Could you please tell me who they are? and what their name is and even where they live? and do that by emailing that to devdays@stackoverflow.com which is our standard dev days address for any kind of dev days question about dev days. |