Beefy Boxes and Bandwidth Generously Provided by pair Networks
more useful options
 
PerlMonks  

Re: Project Boundary

by chromatic (Archbishop)
on Aug 12, 2003 at 22:35 UTC ( #283379=note: print w/ replies, xml ) Need Help??


in reply to Project Boundary

I don't understand why software developers and customers keep insist on trying to fight each other tooth and nail. It's not as if they don't have the same goal.

Insisting that the customer come up with a comprehensive list of requirements before you start the project is silly. You might as well put "The customer can't ever change his mind, ha ha!" in the contract.

Insisting that changes to the scope of work can be fit in to the project as-is without changing the time, resources, or cost is silly. You might as well put "The developers can't ever change their estimates, ha ha!" in the contract.

Either way, trouble's brewing. I don't want to fight with people with whom I have a business relationship.

Aside from, say, the space shuttle, trying to gather requirements (as if they were ripe grapes, waiting to be plucked from verdant vines by barefoot virgins in billowy gauze wraps) up front, once and for all, looks like a recipe for disaster, yet, somehow, "software engineering" still promises it can make wine from unplanted seeds.

What would happen if you agreed to much smaller milestones, one every couple of weeks, letting the customer choose what to do and letting the developers decide how much time it would take?

Maybe it'd take a little more investment from the customer beforehand, but you could avoid the big thud of specifications and negotiations up front and start delivering actual, working code much faster.

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

(Yeah, I wrote a book about this.)


Comment on Re: Project Boundary
Re: Re: Project Boundary
by chunlou (Curate) on Aug 12, 2003 at 22:49 UTC

    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.

Re: Re: Project Boundary
by tjh (Curate) on Aug 13, 2003 at 05:31 UTC
    (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.

Re: Re: Project Boundary
by geektron (Curate) on Aug 13, 2003 at 05:56 UTC
    Maybe it'd take a little more investment from the customer beforehand, but you could avoid the big thud of specifications and negotiations up front and start delivering actual, working code much faster. Maybe customers and developers don't have to fight. Maybe you can both be happy.

    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.

Re^2: Project Boundary
by adrianh (Chancellor) on Aug 13, 2003 at 07:33 UTC
    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

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://283379]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others having an uproarious good time at the Monastery: (14)
As of 2014-12-22 17:58 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    Is guessing a good strategy for surviving in the IT business?





    Results (126 votes), past polls