(Yeah, I wrote a book about this.)

Well yes you did. And, at B&N, when I clicked your name to see other books by you, I got the reply shown here:, which said, among other things, "We found 14,957 titles from author Chromatic," which is of course, extraordinary. You're quite prolific. :) Arthur Chromatic Clark? (Thought you'd get a kick outa your 14,957 books...)

Meanwhile...

It always seems unthinkable that two parties, in this case a programmer and the scope-streaming employer, should so often come to such impasses. They mostly want the same things, but, like so many other similar situations, can't get past an ethos of "the letter of the law (agreement)."

chromatic's urge to work it out so that both get more of what they want is too obviously the most useful approach. Regardless of academic temporizing about the motives of each, or each side's justifications for their behavior, no matter how logical they sound, they still have to arrive a mutually rewarding end result. Otherwise, they are each risking chronic bridge-burning, something harmful to long-term success.

I suppose logjams such as these beget "best practices" in scoping / contracting / deliverables scheduling / sign-offs and the like.

Policies, standardized procedures, rules - all mostly exist to more objectively help regulate what the humans, in the moment, can't themselves manage to take some non-dramatic responsbility for. Those too worried about being taken advantage of create the inverse situation, which is equally charged.

Who really wants to work under a microscopically phrased scoping, that has no willing flexibility for the inevitable product evolution. Coding is simply one more step in the product evolution and often (even "usually") sparks more ideas.

Neither side can afford to put blinders on their partners and expect the best results and creative contributions. But, it does seem to happen all the time.

i have a decent relationship with most of my clients now that i've gone indy, and i don't think there's much fight going on at all.

i've sat down with the client, talked for a couple hours, delivered some 'milestones'/ partially-completed components for preview, and the suggestions for revision fit in nicely.

and if the client wants to have some meeting to feel like "we're on the same page", there's nothing that keeps me from meeting with him/her/them for a period of time, taking the laptop to a cafe with wireless, and showing client what is done, what needs to be done, etc. that way, client is still involved ( but not much ) and there isn't a big hit of last-minute changes and such.

one client in particular has been notorious for scope creep, and all it takes is a quick, firm "that's for our next round", and he's happy and i'm not derailed from the code in front of me.

but it's not foolproof. i have another client for whom i pretty much subcontract, and some of their clients change their collective mind at every term. but that client i charge by the hour. ;-)

Yes, there're indeed still many happy stories out there. I guess engineers tend to be trained as a pessimist.

It probably helps the situation if the client doesn't have or exercise his immerse bargaining power over the developer, such as someone working for a multinational firm, who may think everyone is simply dying to work for them at all costs.

And, o yea, it's always more pleasant if you can simply directly chat with your client instead of his attorneys (happens more often during contract negotiation). We're once bogged down in a negotiation (concerning profit sharing, among other things) for almost a year (the client got plenty of lawyers). In the meantime, the product development and marketing were partially stalled.

O, right. That's why sometimes a programmer should appreciate his business counterpart for getting the verbal bitch-slapping from a client for him, if nothing else.

I guess, the "fight" is partly due to the lack of cross-displinary training in school and at work.

A business folk often found the rigorous nature and process of a programmer inconvenient, whereas a programmer insists the everchanging business world should behave as orderly as the development process. It's a mutual misunderstanding. It's like abs(x) approaching 0 from opposite directions, connected but discontinuous.

Maybe customers and developers don't have to fight. Maybe you can both be happy

Amen brother.

Working projects in a more agile style has made these sorts of requirements wrangling problems disappear for me too. Suddenly I have co-operation instead of conflict. A very pleasant change.

Hi adrianh

It could be interesting to have a description of what
you call "a more agile style".


Regard

Methodologies and practices like Extreme Programming, Agile Modelling, Feature Driven Development, Crystal, etc.

Basically high discipline, low overhead techniques that value customer collaboration over contract negotiation (see the Agile Manifesto).