Jeff: So we have some StackOverflow news, actually quite a bit of StackOverflow news...
Joel: Ok, so let's go on and take notes.
Jeff: Actually, I'm just going to the list, so we should...
Joel: Let me just take attendance here. Jeff?
Jeff: Ah, check. Present.
Joel: Right, and Joel, present. Ok, let's go ahead. StackOverflow news...
Jeff: Ok, Marie (ed: Osmonds?), sounds good.
Jeff: Yeah, we, let's see, we implemented the flair feature.
Joel: Yes, I've been waiting for that. Flair. And you know, the first... I guess I tried the beta, and it wasn't quite working out.
Jeff: Well sometimes what we do is to put stuff on the blog for... really the blog is a small fraction of our overall audience, so... that's a way of sort of beta-testing the features by announcing them on the blog, not really making any explicit links to it on the site, and then sort of see how it works, 'cause what we found is that no matter what we think the feature should be like, and our (?) the feature should work?
Jeff: There's always changes you know, there's always things you didn't think about or... you know... Things people want that...
Jeff: ... we just couldn't think of ourselves, so... We feel like every feature gets changed pretty rapidly after we deploy it, so... That was sort of the intent there, to deploy it, see the feedback we got and make some changes and redeploy. I think we're pretty happy with what we have now.
Jeff: That's right, and there's actually a couple of different internal formats. There's like json, there's like jsonp, there's... bunch of different formats you can choose from to get the data back.
Joel: Yeah, but... but... but... but... but... most people are just gonna want to cut and paste... a blob of code into their html. Presumably.
Jeff: Right, and that should work. I think it was just a styling issue, it was the way the styling was coming down, or not coming down...
Jeff: ... certainly on the blog demo I've been using the iframe just because it's a little bit simpler.
Joel: But doesn't... did you fix the problem where the iframe is coming out with all kinds of extra scrollbars, and... meh, it just wasn't looking right.
Jeff: Make sure you... make sure you copy, when you copy the snippet that there's a bunch of parameters to the iframe you need to set.
Jeff: So, check that, but it should be working.
Joel: I will try that. Tell you what, why don't you sing us a little song... sing us a couple of rounds of row your boat, and I'll try that right now. Citydesk...
Jeff: For what purpose?
Joel: So that I can try putting the flair on my site while our listeners are entertained.
Jeff: Oh, I see.
Joel: So I go to StackOverflow.com, and you listeners can do this to, you go to StackOverflow.com and hit users... no, you hit your name... and.... where's the flair button? You say... users slash flair (users/flair)?
Jeff: Yes, users/flair
Joel: Isn't that weird, if there was a user named flair? Hehe, who is not ... never mind.
Jeff: We actually run into that, it's a routing issue, where the way you name your routes in ASP.NET MVC. If you do it wrong you'll run into conditions where you can't have have a user named "update", and things like that, so you tend to be careful about that.
Chris: Hi Jeff and joel, Chris ?? from the UK here, Thanks for your podcast, I really enjoy it. I have two questions for you today:
Firstly, I want to re-ask a question I've already put on Stack Overflow which is number 204572. This is the question, it's a bit of a business one.
When working for ?? agency how do you win well-priced work? It seems there is so much competition that pricing is driven down very low and hard to argue with the cheapest provider.
I know some client will pay the correct amount for projects but a lot of people are just looking at bottom-line. I feel this line work is very different from a software product company or even an internal IT department in terms of budget.
As joel has said before, like internal IT, we mainly only get to version one of the products. Unless the client is big enough. This means that it does not make business sense in the short term for us to make the product as good as it could be ?? project being ?? budget is.
I was previously working somewhere that always took home work for too little money, and the products were either not up to scratch or the project dragged down until they started to cost the company money to complete the work.
To answer my own question, I believe the answer is to stick to correctly priced work and also to spec extremely thoroughly.
But I'd be interested in experiences you might have had with issues like this.
Question two is…
Joel: I think that the answer that Chris is proposing is not the right answer actually. That you first intuition is better specs and correctly priced jobs, like more nailed down specs and I think that's the obvious answer and obviously everybody's been trying that and yet everybody always has this problem, this is sort of a consistent problem of the small to medium sized build-something-for-you kind of shop. Did this happen at Vertigo a lot?
Jeff: OMG all the time.
Joel: Yea, so that's the size of shop where it happens a lot. And for some reason you don't here about this happening with ten million dollar engagements
that IBM Global Consulting Mega Services does for you. Although– which is not to say they're necessarily any more successful, but they don't seem to get into this problem of like getting an infinite amount of work and we never get paid for it. Maybe they do, maybe they do just as much.
Here's my approach, my approach is you have to understand that just spec'ing something is not gonna solve the problem, if we learnt anything from all the writers on agile software development, the one thing we should learn, it should be that you have to, uh– the spec has to evolve as you develop the code. It just has to. I mean, you can write down as much as you want upfront, which I'm all in favor of, but to then freeze that so that it's the only thing that we can possibly deliver, will guarantee that what you deliver will be, you know, unsatisfactory. 'Cause as soon as you see it you discover these things.
Hey just in this podcast we've probably mentioned ten things that–, not ten, seven things that we saw in the development of Stack Overflow and we changed about the design. Like you said, we'd never have thought that we'd need the ability to make it impossible to delete a question that you put up after it's got good answers, for example.
Joel: So you're not going to solve somebody problem unless you do these things, so this conflict comes from the fact that the client needs you to solve a problem, they don't need you to implement a spec, even if they promise that all they need is for you to implement the spec. You have to stop thinking of it as 'theres a client, and the client has a peice of software they need built, and I'm the software builder, thats the relationship we're going to have, that I'm going to deliver the software product, in exchange for some money', and if you think about it that way you're going to run into this conflict again and again and again. And if you think the way to fix it is to get the client to sign every page in blood, of the spec - have a very detailed spec, and you can say 'nerh nerh I delivered *exactly* the spec', you know, you might win in a court of law, but your not going to solve the clients problem, you're not going to make them very happy, and their going to throw away your code and not ever hire you again.
So, the way to think about this instead is, you have to take a slightly bigger picture, your job is not to deliver some code according to a spec, your job is to get into the clients shoes, and figure out what their problem is, what ever their problem way be that can be solved with computers, or something that you can build, and propose to them a complete solution to their problem whatever it might be. That means that you have to be involved in the design, and when you're invovled in the design, you have to be looking at it from the clients perspective, not from your perspective, as a software developer that just wants to get paid - and your perspective is, 'gosh, I'm hiring these guys, I'm paying them the equivelient of $45 an hour, I've got charge at least $65 an hour just to break even, and therefore maybe I'll charge $75 an hour for my profit, and lets say $80 an hour to include all the things that are going to go wrong.'
Thats not your clients perpetive *at all*. your clients perspective is, 'we are loosing invoices left and right because the system that they're going into just shreads them all in some bad way, and this is costing us money.' And thats the problem that your're being hired to solve, and so you go in there looking at that problem, and you have to see it from the clients perspective, you have to see it from, like, the clients Return-on-Investment, and you have to be thinking about, 'what am I building, how is this going to solve a clients problem in way that makes sense to their balance sheet', like you have to think about their business, and you have to make sure that your building them something that is cost effective for them and will have a positive ROI for them, and if you're not thinking about it at that higher level, if your just coming in saying, 'I dun know, I just write the code', then you're just a code monkey and your not doing anyone any good, if you are thinking about it from their perspective, if your taking the same approch as the CEO of the company would take that hired you, which is, 'this better be worth the money that I spend on it, or I'm going to be pissed', then your going to have a successful engagement.
Jeff: Well thats a great answer, and I think it hightlights one of the core issues, which is, the more I though about that, you end up being adjunct employees of the company that you're doing work for, and you really have to approch it that way.
Jeff: its very wholistic, so you have to be willing - cause I found this in engangements where I was in this situations, you become a proxy employee of that company.
Jeff: Which can be cool, if the company is cool and you actually like the things that they're doing, and they make sense to you, but alot of times we go to companies where , it didn't really make any sense, like you didnt really want to be there, you didnt want to be an employee of this crazy company, that your working for. Even in an adjunct fake way. It was sort of unsatifactory. Its almost like you end up being part of this family that you didnt really sign up for.
Jeff: So you have to be really careful when taking on engadgements like that. And honestly I don't even like that business model, at all, as a programmer, like I think that you should have a packaged product, I think thats much better than doing bespoke stuff. In the big scheme of things.
Joel: Well, Sure, but if you're in that business at least you should understand that you're in the solutions business. Did we talk about the coffee maker thing? Where did I get this...
Jeff: I don't think so.
Joel: Ok, so...
Jeff: Give me a little bit.
Joel: So, lets see... What was that book called? Something about 'how to castrate a bull'?
Joel: Lets just google that. - 'How to Castrate a Bull'. This is a book by Dave Hits, who founded the company NetApp, which makes those big file sharing - file servers. They're these IP based, enterprise data storage company. NetApp. And this is the kind of book where he just tells the story of creating NetApp, which is the kind of book that has absolutely no literary merit whatsoever, but I read them all. Always. Just automatically. If its a book about creating a high tech company, I will read it.
And, anyway, so he tells a story that I thought was really interesting about what it means to be enterprise software, and like, whats the difference between enterprise software and off the shelf software. And whats the difference in the type of clients, and he tells a couple of stories, the first story he told which I thought was really interesting, is the first time he tried to make an enterprise sale he went down to Georgia Pacfic, and he had his little NetApp under his arm, and he gets up and he
Jeff: I actually have a Stack Overflow question we could do, if you don't mind?
Joel: Yeah, let's do.