⚡️Release early, release often is not as easy as it seemsSaturday, July 5th, 2008 at 2:38 pm
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.