I've been a programmer for many years. I've seen projects succeed and
projects fail.
Someone has said that managing programmers is akin to herding cats.
Programmers put blood, sweat, tears, and ego into their code (or at least
they should!).
For many programmers, their code is their art.
When this is the case, they - quite naturally - become protective of their
code.
With this philosophy/scenario, there can rarely be smooth roads.
One of the philosophies that I had the unfortunate experience of working
under was 'egoless code'.
Yeah, sure.
Sounded good to the managers. It rarely worked in reality.
One strategy that kinda/sorta worked was "code walkthroughs".
It was understood beforehand that these were code walkthroughs, *not* "code
walkons".
The programmer invited other programmers to a conference where they could
comment on (not criticize!) the programmer's code.
The invitees did not need to be familiar with the project.
It brought the programmer out of the solitary environment that we get into.
It was, for the most part, a learning opportunity for all involved.
It also increased respect for other's coding ability.
Another suggestion is that the teams pursue a common,
*well-defined*cooperative (read: non-competitive!) objective.
On Sun, Jul 3, 2011 at 2:50 AM, Ross Gardler wrote:
> Hi Ted,
>
> I think the warning in your mail should be heeded. Whilst there are
> opportunities and established practices for collaboration on shared
> code, ensuring the collaboration happens can be difficult. It requires
> a certain level of humility, patience and effort on the part of all
> involved.
>
> Since you are obviously concerned about this do you have any ideas
> that can help us develop the right relationship for collaboration
> between the different parties involved?
>
> Ross
>
