Software Hazing

(however, for full disclosure, my mother tells me that she and my father were once called to school and I was threatened with suspension for engaging in hazing. I believe was 6 years old and In the second grade. I don't actually remember what I did but apparently it constituted hazing)

Now the liberal-elite, gotcha mainstream media are quick discount hazing as nothing but a boys (or girls)-will-be-boys ritual directed at humiliating individuals simply for the sake of feeding the ego of perpetrators. While it can certainly sometimes fall to the level, as Dr. Cialdini discusses in his book Influence, hazing's raison d'etre is much deeper than simple cruelty. In the chapter "commitment is the key", he explains:

The Thonga tribesman with tears in his eyes, watching his 10-year-old son tremble though a night on the cold ground of the "yard of mysteries" ... these are not acts of sadism. They are acts of group survival. They function, oddly enough, to spur future society members to find the group more attractive and worthwhile. As long as it is the case that people like and believe in what they have struggled to get, these groups will continue to arrange effortful and troublesome initiation rites. The loyalty and dedication of those who emerge will increase to a great degree the chances of group cohesiveness and survival (Influence, Robert B. Cialdini, 78)

One of the quirks of human nature is that we value things based on our level of commitement. The more effort and energy we expend to achieve something,  the more we will value the result. The same goes for membership into organizations - groups that are difficult to become a member of will invariably be valued by their members more than groups that allow anyone in, even if they provide the same or similar services.

There is a corresponding desire, having fought tooth and nail to gain entrance into a group or community to play "gatekeeper" and ensure that anyone seeking admittance to the group has to go through the same trials that you did, otherwise your own sacrifice will have been worthless.

Software developers, I believe, can sometimes put barriers around their software for those two reasons. The question is whether we doing it for "good reasons" (because it generates a stronger commitment and devotion) or "bad reasons" (because if we had to go through it, you darn well do too), or a combination of both?

For an example of the former, take the VI editor - there is a lot that could be done to make the editor more user friendly - but something would definitely be lost regarding the exuberance of it's zealous fan base if it could be mastered in a day of puttering around (For those of you so inclined, take the word VI and replace it with Emacs and you get the same result ). I don't think that sort of exclusiveness is necessarily a bad thing as by creating a more excited user base, everyone benefits. A motivated user base that actually pushes the product and adoption of the product forward is a great thing.

For the second example, any time you ask a developer a question they know the answer to and they respond with "look at the code" - or pulling from previous personal experience - walk over to your desk with a 500 page ISO specification document and tell you to look it up - I don't think anyone is benefiting. As individuals a little bit of a helping hand getting started goes a long way towards making progress on just about any task.

A couple of years ago, having used a small open source utility I sent a note to the author asking if they needed help fixing a bug I had discovered. Their response - "sure, just send us a patch" - while perfectly valid, seemed to have some of the gatekeeper mentality. "Prove yourself, and then we'll talk." Having no knowledge of the codebase and no one to help me get started, I got discouraged after a couple of hours of debugging and used something else. No one ended up benefiting. A two line response of - "Sure, check fizzbuzz() in foobar.c" would probably have been enough.

So, one of the goals we have with launching Webiva is to try to make it a friendly piece of software to get into - whether you're a seasoned programming veteran or just a user who wants help. I'm not saying it's going to be easy as there is some significant complication innate to the software, but we'll be there to offer a helping hand for anyone interested into getting into it. And, we promise, no livestock.