DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports Events Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
  1. DZone
  2. Popular
  3. Open Source
  4. Zen and the Art of Collaborative Software Development

Zen and the Art of Collaborative Software Development

Brian O' Neill user avatar by
Brian O' Neill
·
Jan. 28, 13 · Interview
Like (0)
Save
Tweet
Share
4.35K Views

Join the DZone community and get the full member experience.

Join For Free

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)

Software development Collaborative software Open source

Published at DZone with permission of Brian O' Neill, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

Popular on DZone

  • AWS Cloud Migration: Best Practices and Pitfalls to Avoid
  • Select ChatGPT From SQL? You Bet!
  • 5 Factors When Selecting a Database
  • Top Three Docker Alternatives To Consider

Comments

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com
  • +1 (919) 678-0300

Let's be friends: