[ November 15, 2007: Message edited by: Ilja Preuss ]
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Joined: Jul 11, 2001
With other words, software development is not best thought of as a couple of tasks that are worked on individually, it's a team effort, with lots of communication, creative thinking etc. pp. And you don't optimize the productivity of a team by having everyone work on his own task.
Originally posted by Marilyn de Queiroz: I've seen situations where the client is fearful of pair programming ... doesn't want to pay for 2 developers to do the work of one (so to speak). How would you address the client's concerns?
Is it just pair programming or is the client concerned with agile over all? For example, can you give estimates on a higher level rather than per developer? If all estimates are on the task level, the client shouldn't have to know or care how you go about implementing it. That's the project manager (or team's) job.
We don't pair program all the time. Or regularly for that matter. But when we do, we don't inform the customer. Sometimes we discuss with management that mentoring would be helpful in that situation. Or that it would be a particularly useful task to pair on for knowledge transfer or criticality. Sometimes two people just decide that it would be the most efficient way to accomplish the two tasks. If both tasks are accomplished during the estimated time, why should the client care who worked on them?
Or is this a case of the client hiring contract programmers individually rather than dealing with the concept of a team? [ November 14, 2007: Message edited by: Jeanne Boyarsky ]