Any sufficiently advanced technology is indistinguishable from magic.
Arthur C. Clarke
Its been talked about before, but while reading the 'The God Delusion' by Richard Dawkins (and no he doesn't Twitter!), the meme of the Cargo Cult once again caught my attention.
Cargo Cult: Waiting for Frum
Anthropologists have observed the phenomenon of island inhabitants (most famously of Pacific Melanesia and New Guinea) mimicking and performing rituals of visiting advanced cultures in the belief that these acts will provide them with material goods and wealth. This phenomenon is known as a Cargo Cult.
The islanders observed that the visiting people enjoyed great luxuries, with seemingly little or no useful work required in return - they sat behind desks while new or repaired items appeared on the island as if by magic.
In one instance, on the island of Tanna in the New Hebrides (now known as Vanuata), the islanders awaited the return the messianic Mr John Frum who would bear bountiful cargo. Supposedly arriving by plane from America, the islanders cleared an airstrip and installed a bamboo control tower, replete with wooden headphones. They still await his return.
In our technologically advanced, self-actualising, networked society, cargo cults are still in full effect.
The Cult of the Internet Gods
With new social networking tools emerging on the net every day, users scrabble to adopt these applications in the hope of increasing their social network status. A case in point: Twitter. A few in the industry have risen to deified status, having built large networked tribes with thousands of followers. 'Lesser mortals' reply or re-tweet these Twitter superstars in the hope of building their visibility and profile.
The cult of the social media tool is further expounded with the concept of the invite-only period. The exclusivity built around the new network heightens user desire to be included and follow in the keystrokes of the privileged early adopters. As these tools grow and permeate, the onus is on people to opt in to these new networks - or fear missing this new source of flow information.
That being said, this phenomenon does propel the ideas and tools in that space forward, helping refine processes and opening the network for use in unexpected and innovative ways. The mass take-up of the network helps progress the tool and inevitably leads to a disruptive leap to the next social network tool.
Users also quickly determine if the tool is of real use in their daily workflows and can decide to opt out of that particular network stream.
Cargo cults with less satisfactory results can also be found in coding practices.
The Cult of Copy And Paste
At times, we need to replicate a piece of code from one code-base in another project/application. For the times when the functionality cannot be extracted out to a utility library, the temptation to simply copy the code can be strong. The application may even work as expected during testing and it appears that some time may have been saved. At some point, however, copy'n'paste karma may come calling back with problems.
Time should be taken to understand and verify what each line of the replicated code is doing. Is each line necessary? Is there a subtle change required to achieve the goals in the new code-base? Answering these questions can avoid problems and unexpected behaviour and gives the developer confidence in knowing the flow of the application.
The Cult of Scripting
Build systems and deployment scripts can sometimes be arcane pieces of dark magic - Maven still confounds me! Often written in languages that require real expertise to understand subtle nuances, developers can be left executing scripts which they know little about other than the final (hopefully successful!) result. This lack of understanding can lead to problems.
On one banking application I worked on, a set of build scripts was employed to deploy an application into the target environment - configuring the database and the application server. The development team was given little information on the intention of the scripts, with only sample scripts from another project as a guide.
New scripts were developed (copied!) and executed. However, soon after application initialisation, problems with database connections were reported and the application would need to be restarted. For each deployment, the release engineer was requested to run all the scripts. Upon further investigation into the nature of the scripts, it transpired that one of the scripts was only required to be executed once at the outset of the project, in order to configure the database and connections. Thereafter, only the application configuration scripts were required.
Build and deployment scripts can be difficult and time-consuming to deconstruct. In this respect, breaking the task into discrete parts can help, by aiming to understand small sections of the script at a time. Learning to understand the intricacies of the process can lead to resolution of issues as described above, or improvements in the overall process workflow.
So, is your code expecting the return of Mr Frum anytime soon?