Hacker News Reader

> To me it looks like he is just trying to nickel and dime for everything little change.

For $800 you bet your ass the developer will nickel-and-dime. After all, he was nickel-and-dimed.

By whom? The system? The developer bears at least a little responsibility for submitting a bid that is too low to cover successfully completing the project.

>The developer bears at least a little responsibility for submitting a bid that is too low to cover successfully completing the project.

I didn't say he doesn't.

The guy talked the developer down to an $800 fee, and then his interpretation of the agreement was the developer should take his feedback into account after the code was submitted to him ("I figured some graphics changes would be OK. Basically, the overlay graphics are slightly different. Same functionality"). That's definitely a self-serving interpretation. Clearly the dev does not want to do anything more than he absolutely needs to do. For that amount of money, he wants to knock-out an app in minimal time and move on.

So I'm saying they both nickel-and-dimed each other. I'm not judging, but that's what happened, and I have slightly more empathy for the developer in this case.

Also this is written from his perspective. It's most likely he forgot (or deliberately didn't mention in this article) everything the developer said during those negotiations, presumably things like "we will have to negotiate additional charges for anything not specifically mentioned in the spec."

Sure, fair enough, but roughly zero projects are going to succeed with that sort of minimal approach. It almost guarantees the client will have to pay for additional work.

I was only being slightly facetious, though -- the system really does suck and I think deserves most of the blame.

no the dev doesn't

Mike, in his own words:

    I went through the app, listed out the bugs I was finding for each 
   component, mocked up a couple small graphical changes, and sent them over to 
   the developer.

bugs are covered under a fixed price contract. Changes aren't. And Mike is a marketer / photographer; do you really believe he has any idea of the difference between a "small graphical change" and something that requires a code change? The developer is at fault only for agreeing to any changes without a price increase.

And thus the classic problem with fixed price contracts: when I've done them I've been really clear with clients that no changes are included. Bugs yes, but every change is a renegotiation. Now often the lines between those two are a bit blurry, and I try to give clients the benefit of the doubt. But I bid to a very specific spec, and what can seem like a tiny change often goes against the grain of assumptions built into the code and is anything but tiny. To a person, clients agree then whine down the road when guess what, that change is a price increase. Sigh. The answer is to not do fixed price; it just sets you up in a very adversarial relationship with your client.

Plus, well, if you pay bottom price you get bottom quality.

Sometimes, non-technical people don't (or can't) tell the difference between a "bug" and a "change". when the thing doesn't do what they expected in their mind's eye, its a bug, not a change. A change is when a completely new feature that isn't mentioned in the spec.

So "bugs" like, moving a menu around, or swapping screens seems easy to someone who has never written anything before, but it isn't trivial (unless, of course, you had time to write nicely abstracted code. But for $800 and two weeks, i doubt that's the case).

May be there should be an app that lets clients make mockups, and when they change their mockups, it computes a "diff" that then is heuristically used to generate an expected price...

That's why change orders should happen for anything that isn't specified at the time of signing the contract. They can be zero cost, they can be clarification change orders, they can swap scope, or they can involve additional cost.

I try to get to a cadence of about one change order a week on projects lasting longer than ten weeks. Sometimes, depending on how onerous getting an SOW signed can be, we'll even queue up change orders (with the client's willing participation) to execute right after the SOW is approved by legal.

There are plenty of apps that version mockups, but it's also possible to add layers to existing documents as well, whether it's photoshop, visio, etc.

Yeah, except for the fact that the developer is the one who sent the quote.

I've reached the point this year where I've concluded that the correlation between "bad client/employer" and "low pay" is so high that I treat that correlation as 100% and immediately rule-out such parties upfront before risking investing my time/energy into them. The correlation has not been 100%, but close to it. In actual practice.

(And by the way: fuck theory and fuck words. I only look at what happens in directly observed and touchable reality anymore.)

"(And by the way: fuck theory and fuck words. I only look at what happens in directly observed and touchable reality anymore.)"

Heuristics have been shown to be highly effective.

totally agreed. though I hope you meant that in a completely non-sarcastic way. :-) (because I know there's a vein here on HN that believes every positional claim must be backed by some scientific paper.)

there are many negative things to getting older. but one good thing is you accumulate a larger set of direct RL observations and experiences, out of which you can see certain patterns, some good, some bad, and certain correlations. Treating these correlations as black-or-white indicators can potentially be bad if it closes you off to opportunities. But it can also close you off to bad experiences. You might lose on the small/near-term but you win more in the aggregate and in the long run, playing the odds to your benefit.

>totally agreed. though I hope you meant that in a completely non-sarcastic way. :-) (because I know there's a vein here on HN that believes every positional claim must be backed by some scientific paper.)

I was being serious, and it might humor you a bit when I tell you there are numerous "scientific papers" that back the effectiveness of heuristics (google heuristics case study to find some).

Look at it the other way- the people who want $800 apps are the ones most likely to withhold payment or give bad reviews.

The developer is probably working from hard-won experience, the client in this case is not.

I think its prudent for the dev to set expectations straight away. I would expect most people to be reasonable, but that most people, if they had their initial expectations broken, would feel cheated.

So the art of consulting/free-lancing is to make sure reality matches expectations. For both parties.

Of course, there are clients that expect a facebook for $1000, but if the dev makes sure to set out such expectations at the start, and don't agree until something is signed and sealed.

What may be a "change in the way it looks" to the author could, in fact, be a change in code.