/>
X

Perfectionists need not apply

If you're a perfectionist, or prefer to solve problems alone, you're going to have some problems working with community projects. Individual contributors and companies need to get used to working in the open, and be willing to work towards perfection rather than trying to nail it the first time.
joe-brockmeier.jpg
Written by Joe Brockmeier on

If you're a perfectionist, or prefer to solve problems alone, you're going to have some problems working with community projects. Individual contributors and companies need to get used to working in the open, and be willing to work towards perfection rather than trying to nail it the first time.

I was reminded of this after stumbling on this brilliant post by Drupal maintainer Angie Byron. Byron does a character study of two potential contributors, and their approach to submitting a patch to the project. The lesson? The perfectionist isn't the most desirable contributor.

While Drupal itself is clearly an open, Bazaar-style project, many individuals in the Drupal community tend to take the perfectionist approach to development. After all, *thousands* of people will be using this code, and likely *hundreds* of developers carefully inspecting its inner-workings. How embarrassing would it be for another developer to stumble across a "no-brainer" bug in your code? Best to sit on things until you know it's really solid before putting it out there in front of people. Right?

Sure, that sounds logical. But in my experience, people who take this approach to development in an open source community, and especially the Drupal community, are at a severe disadvantage to those who embrace the chaos and put their changes out in front of everyone as they're going along, warts and all.

The lesson here is that the open source model is a collaborative effort. That doesn't mean that a lot of communication will make up for really lousy code -- but the people who succeed are usually those who are in the thick of it day in and day out, and who work well with other developers.

This is a hard lesson for developers with a proprietary background to overcome. For corporate-sponsored projects, the first impulse seems to be releasing code when it's "ready" for a release. Then perhaps releasing features to a public code repository when the features are ready.

But really, the only way to do it right is to work in step with the community -- meaning, making the public code repository the official repository, rather than doing work behind closed doors and then sending it out to the world.

Related

He flew American Airlines, she flew United. For both, the unthinkable happened
screen-shot-2022-06-30-at-10-14-36-am.png

He flew American Airlines, she flew United. For both, the unthinkable happened

Business
Giant data breach? Leaked personal data of one billion people has been spotted for sale on the dark web
close-up-of-a-womans-hands-typing-on-a-keyboard-in-the-dark.jpg

Giant data breach? Leaked personal data of one billion people has been spotted for sale on the dark web

Security
Southwest Airlines has cancelled 20,000 flights. Now for the really bad news
screen-shot-2021-07-07-at-4-01-12-pm.png

Southwest Airlines has cancelled 20,000 flights. Now for the really bad news

Business