A cargo cult is a type of religious practice that has appeared in many traditional tribal societies in the wake of interaction with technologically advanced cultures. The cults are focused on obtaining the material wealth (the “cargo”) of the advanced culture through magic and religious rituals and practices, believing that the wealth was intended for them by their deities and ancestors.
From time to time, the term “cargo cult” is invoked as an English language idiom to mean any group of people who imitate the superficial exterior of a process or system without having any understanding of the underlying substance.
From the Wikipedia Cargo Cult Article.
You may be familiar with the story that our (the UK that is) Prince Philip (The Duke of Edinburgh) is venerated as a god by the Yaohnanen tribe on the southern island of Tanna in Vanuatu. A similar thing happens pretty much every single time a shiny new ‘paradigm shifting technology’ pops up the the Ruby world.
It seems to me that the majority of people in our community abandon common sense and general good practice to jump aboard the shiny new ship without any real examination or thought going into evaluating some very important things:
Instead, what appears to happen is the following process seems to be followed:
This is doubly true if it’s some new fangled way of doing Buzzword, whoops, no, Behaviour Driven Development. The biggest winners lately from this Cargo Cult Nature of Ruby developers are the projects RSpec and Cucumber, brainchildren of Aslak Hellesøy but now supported by a large and enthusiastic community.
For those of you who don’t know what BDD is:
BDD is a second-generation, outside-in, pull- based, multiple-stakeholder, multiple-scale, high-automation, agile methodology. It describes a cycle of interactions with well- defined outputs, resulting in the delivery of working, tested software that matters.
“Agile Specifications, BDD and Testing eXchange” in November 2009 in London, Dan North
The definition of the concept and the Wikipedia article about BDD both read like an MBA’s wet dream, or a Vision Statement from Dilbert. Personally, I don’t see the benefit of ‘BDD’ over a good ‘TDD’ development process and largely view it as a marketing-hyped-up version of what already existed; but that should be the subject of another post.
When RSpec first turned up, my colleagues and I were skeptical of what seemed to be a re-invention of the wheel with regards to software testing in order to wrap it up in a prettier syntax to make it more intuitive for a developer to write and a non-developer to read. This was some time ago in late 2007 / early 2008.
Rather than jumping in and re-writing existing tests in this shiny newness, we decided to write the tests for a new piece of functionality we were working on using RSpec and to see if it added any value over regular Test::Unit tests.
For our purposes, we found it didn’t. We ended up writing horrible monstrosities of text to try and mash what we were trying to test into the format / way RSpec expects.
What happened in the end? We have about 10 ‘spec’ test files in our suite and hundreds of test/unit tests. All new tests are written using test/unit because after our evaluation we found that the shiny new hotness wasn’t suited to our needs.
These days the cargo-culting seems to be focused around whatever the Rails Core Team says is good, and this largely is not a bad thing in and of itself, some very knowledgeable people are making recommendations based on their own experience. They tell you what works for them and (sometimes, but rarely), why and people follow where they (as ‘community leaders’ lead).
The problem with this is that very little thought is being applied by the people doing the following. Blindly following someones' recommendation stifles free thinking and creativity.
If you think I’m off the mark with my thoughts on the cargo cults; think about this: Are you a Ruby / Rails person, and are you using an Apple computer? Congratulations, you’re a follower of the Ruby-People-Use-Macs Cargo Cult (as, I must admit, am I).