|Perl: the Markov chain saw|
(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...)
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.