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 give sthe same demo he's been doing successfully for years, he talks about, like TerraBytes per second, and how many - how much data storage the thing has, and the protocols that his device talks, and how it doesn't have an operating system, and all kinds of like really technical stuff, and how much cheaper it is that the competition.
And the head of the IT department there goes, 'Son...' - except I can't really do a georgia accent, so pretend I'm saying this in a deep south accent - he says, 'Son, we cut down trees and make them into toliet paper, tell me how your device is gonna help us cut down trees and make them into toilet paper'. And of course, needless to say, they did not win that particular contract.
Jeff: Right, well, thats what I'm saying, when you work for a company that cuts down trees and make them into toliet paper, you have to have some enthuseasim for the process of cuting down trees and making them into toliet paper. You really really do! Thats where it became problematic for me. When I worked with clients that I liked, that I thought had a cool business model, it was fun, it was great.
Joel: But heres the thing, if you do want to sell to geogia pacific you have to go in there an tell them something that helps them cut down trees and make them into toliet paper. Because thats the language that they speak, and you have to solve that kind of problem for them. You can't nessacarily expect them to do the translation for you, into what peice of code that they need. And when you do make that kind of sale, thats where you get rich, because thats where you can charge vastly larger amount of money, because you're solving a problem, your not just a code monkey, you're not working hourly, you're actually coming in and fixing a problem, and that may be worth a great deal of money to somebody.
So he gave this other example, which he just imagined. He's sitting in the hotel room, and he sees the little Mr. Coffee that they have in every hotel room. And he thinks about like, what does Hilton Hotels, with their thousands of hotels around the world, how do they get this Mr. Coffee to be in every hotel room, and functional, working, like not broken. Like how is it not broken.
And he said, well, you could do it the obvious way, which is, alright a Mr. Coffee Coffee machine costs $36 and I'm just going to order them the cheapest way possible and I'm going to order a thousand of them and deliver them all over the world, and if one of them breaks, I don't really know what I'll do, I guess the customer will call down to the front desk and - But you don't really want to happen right, you want somebody checking these things to make sure they keep working, and you need someone to bring coffee to the rooms and you need somebody to update them if they're starting to look kind of shabby.
You actually - you have this problem, this coffee-maker-in-room problem, and just buying the coffee makers only solves about 20% of that problem.
Jeff: I see.
Joel: Actually getting the coffee maker into the room doesn't create a system for the coffee makers to be repaired and replaced when they break, and detected when they're broken, it doesn't create a system for the coffee getting in the rooms it doesn't - theres all kinds of stuff around making a successful coffee maker in the room that you might have to do and you don't really want to. So what you want is a company you can just contract with to make sure there is always a coffee maker in every room and it always works. And for this you might pay, 4 times as much as the actual cost physical cost of the coffee maker, cause theres a service thats coming with it.
And for those of us in the software world that is the enterprise sale. Thats what is means to be enterprise-y, when you make an enterprise sale, you don't go in and you say 'I can deliver 10,000 widgets' or 'I can give you 10 seats of FogBugz', or I can give you whatever this particular peice of software is that you can also buy on the internet.
What you're doing is you're going in and saying, 'I will come into your shop, and figure out what your problem is, and I'll discover what the problem is, and I'll make a system for solving this problem that just happens to use some product that my company supplies, and I'll supply the product, and then I'll supply consultants to install it, and then I'll supply people to train you and I'll get the whole process up and running and I'll supply people to run the process if you want, and you'll just describe your toilet paper making problem and I will solve the whole thing.'
And thats why, you know, IBM and Microsoft Consulting Services, like these big - the big consulting firms go in, and just charge $200, $300 an hour, and thats why the little consulting firms go in and charge $80 or $90 an hour, because thats the difference between providing, sort of the complete package where its like, 'I will solve a problem and figure it out', whether or not you're successful verus just I will give you warm bodies that will sit in chairs and type any code that you tell them to type.
Jeff: Doesn't sound very appealling does it?
Joel: No, I don't - completely awful. They all sounds terrible.
Jeff: Hahah. But I love you're analogy with the coffee makers, thats exactly the point.
Jeff: I actually have a Stack Overflow question we could do, if you don't mind?
Joel: Yeah, let's do.