Release early, release often is not as easy as it seems

Ben Collins-Sussman, Subversion godfather and one of the men behind Google Code wrote an interesting article about Programmer insecurity in which he realizes that the whole concept about “Release early, release often” is not as common as we think it is.

And yet over and over, I’m gathering stories that point to the fact that programmers do not want to write code out in the open. Programmers don’t want their peers to see mistakes or failures. They want to work privately, in a cave, then spring “perfect” code on their community, as if no mistakes had ever been made. I don’t think it’s hubris so much as fear of embarrassment. Rather than think of programming as an inherently social activity, most coders seem to treat it as an arena for personal heroics, and will do anything to protect that myth. They’re fine with sharing code, as long as they present themselves as infallible, it seems. Maybe it’s just human nature.

Yes it is, and overcoming the barrier to allow people to point out your mistakes to you for fixing is quite a hard step for a lot of people.

One main reason is that the job market doesn’t necessarily help us in getting there: bad managers still promote developers in terms of what they can produce in a certain amount of time or how much they know themselves. Clever managers encourage knowledge sharing and make sustainability of your code a necessity for promotion. If you can deliver good code and you can make yourself replaceable by people reporting to you, that is good for the company and the product. It also means that you can have a holiday once in a while. However, far too often this way of progressing is seen as weakness or “losing touch” or “becoming a manager and not a coder” by your programming peers. Coalfaces we ain’t, so let’s stop with this.

Back to opening up your code early and often and invite feedback all the time. I do appreciate that some people don’t want to do that. It is not about releasing “perfect code” but it actually is about protecting your idea or principles.

Say you wanted to create a JavaScript library that only does one thing right: patching browser bugs in DOM and CSS support and allowing developers to really use the W3C recommended methods instead of branching for browsers. Releasing this library would more than likely result in a flood of requests to “add animation – everybody needs that!”, “make it like jQuery – just smaller” and similar requests. Developers are amazingly gifted in listening to the “feature creature” (think of Jabba’s little evil cackling mate in Star Wars) on their shoulder instead of keeping what they deliver down to the bare necessities. Feedback like that early in the process is very distracting and also disheartening. It is not about how much you pack in – it is about fulfilling the task you set out to fulfil.

Tags: crowdsourcing, developing, open source, programming, version control