For me, this perfectly sums up how you should approach client work and building meaningful client relationships.
Your first intuition is better specs and correctly priced jobs, like more nailed down specs. I think that's the obvious answer and obviously everybody's been trying that and yet everybody always has this problem, so this is a consistent problem of the small to medium sized build-something-for-you kind of shops. And for some reason you don't hear about this happening with ten million dollar engagements that IBM Global Consulting Mega Services does for you, 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 never getting 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 learn anything from the writers of agile software development, the one thing we should learn should be that 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 unsatisfactory. 'Cause as soon as you see it you discover these things.
You're not going to solve somebody's 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, "There's a client and the client has a piece of software they need, and I'm the software builder. That's the relationship we're going to have and I'm going to deliver the software product in exchange for some money". 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 of the spec in blood - i.e. have a very detailed spec so you can say, "nerh nerh I delivered exactly the spec", then, 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, whatever their problem may 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 involved 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 equivalent 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."
That's not your clients perspective at all. Your clients perspective is, "we are losing invoices left and right because the system that they're going into just shreds them all in some bad way, and this is costing us money." And that's the problem that you're being hired to solve, 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 client's problem in a way that makes sense to their balance sheet?". You have to think about their business and you have to make sure that you're building them something that is cost-effective for them and will have a positive ROI for them. If you're not thinking about it at that higher level, if your just coming in saying, "I dunno, 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 you're taking the same approach 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 you're going to have a successful engagement.
Edited from the StackOverflow Podcast #54 transcript