Zen and the Art of Collaborative Software Development

Conway's law suggests that designs are constrained by organizational communication structures.  I've seen that law manifest itself over and over again and I'd assert that it is impossible to develop a cohesive software platform unless the proper collaborative dynamics exist.  Specifically, to develop a software platform that can satisfy the needs of many different product-lines, consumers, and/or dependent projects, you want those dependent projects to be able contribute back and co-develop the platform.  This approach shares ownership, shortens the development life-cycle, and enables innovation across the organization.

It follows that the dynamics required to develop a platform are different from normal silo'd team dynamics.  The dynamics you need mimic that of the open-source community.  Developers need to be good citizens in a larger community.  Here is what I think that means:

First.  Be Self-Aware. 

There are four stages to mastery: Unconscious Incompetence, Conscious Incompetence, Conscious Competence, and Unconscious Competence.   It is very important to know where you are on that progression before you interact with a community. 

If you aren’t self-aware, you run the risk of making an unfounded assertion when a question may have been more appropriate.  (We all know the A-hole that emails a discussion list making claims before doing his/her homework)   Thus, I’d recommend always starting from the conscious incompetence perspective and communicate with that tone.  If you are new to a project, communicate via questions to confirm assumptions before making assertions.

Once you’ve achieved conscious competence, help others out!  Take questions from others, and propose solutions to them politely and in an open audience.  Everyone will benefit from the ensuing discussion and it will enable innovation.  You may have a solution that others can improve upon, but the tone should remain propositional.

As you progress to Unconscious Competence, swtich from proposing solutions to delivering them.  Instead of simply proposing solutions in email, you should be submitting pull requests with working code.

Second. Be aware of a project’s maturity.

Early on, projects are trying to pickup momentum.   They may be throwing stuff at a wall to see what sticks.  It is important to recognize that. Often, in the early stages of a project the participants are trying to demonstrate the most amount of value in the shortest amount of time, which is one way to get a project funded / off-the-ground.   If a project is in that state, complaining about configurability and elegance of interface might not be the best idea.

Third.  Be aware of others.

(IMHO) Passionate rock-star developers are often arrogant and obsessive-compulsive.  Those great developers want things their way, and they believe they have the best solution.  (Myself included, I must have been an asshole to work with early in my career)

As you start collaborating with larger communities of developers, you realize that beauty is in the eye of the beholder.  You can appreciate other’s perspectives with an increased tolerance for other ways of doing things. (other coding styles, languages, and best practices)

Finally, I think you get to a place where you can listen to others’ ideas without feeling an immediate compulsion to improve upon them.  This is powerful, especially for seedling ideas.  Passion for an idea is a fickle thing.  Sometimes its more important to keep your mouth shut, and let a peer evolve an idea before suggesting improvements and vocalizing all the nuances, edge cases, and counter examples that might make it difficult.  You never know what might grow out of any random thought.

As a corollary, it’s important that people feel welcome to bring ideas out into the open.   If other people don’t feel that they can bring ideas to you, or you feel you cannot bring ideas to them, it is YOUR fault and no-one else's  Its important for each citizen to own that dynamic and ensure the atmosphere is conducive to innovation.

IMHO, these dynamics are essential in any successful collaborative community.  Furthermore, such dynamics are cultivated by successful benevolent dictators. (shout-out to @zznate and @spyced, two of the better dictators I’ve met.)  

We had a great discussion on this topic at Health Market Science (HMS), where we do a lot of open source work.   Incase anyone is interested, I posted the slides that drove the conversation. 

http://www.slideshare.net/boneill42/collaborative-software-development

Hopefully people find it useful.

(tnx to @jstogdill for the mentoring over the years)