If there is one work-related term that got stuck in my head it is “cargo cult“:
In the South Seas there is a cargo cult of people. During the war they saw airplanes with lots of good materials, and they want the same thing to happen now. So they’ve arranged to make things like runways, to put fires along the sides of the runways, to make a wooden hut for a man to sit in, with two wooden pieces on his head for headphones and bars of bamboo sticking out like antennas—he’s the controller—and they wait for the airplanes to land. They’re doing everything right. The form is perfect. It looks exactly the way it looked before. But it doesn’t work. No airplanes land. So I call these things cargo cult science, because they follow all the apparent precepts and forms of scientific investigation, but they’re missing something essential, because the planes don’t land.
It seems the software industry is a particular easy victim for applying “cargo cult” technologies or management strategies, since there are usually no obvious, physical effects associated with it. Detecting and eliminating “rituals that serve no purpose” would itself require some understanding of the situation, which is the exact opposite of what “cargo cult” means. Essentially it’s a lack of understanding or maybe even willful ignorance. You need a lot of courage to change the rules of existing systems, so it’s easier to just rename them or introduce new rules that can not conflict.
In contrast to some discussions we observe in the software community, agile development is not about cargo cult adoption of Scrum or any other process, toolkit, or methodology — although we certainly observe this and consider it a problem.
Frank Buschmann and Kevlin Henney, Architecture and Agility – Married, Divorced, or Just Good Friends?, IEEE Software 3⁄2013
When it comes to agile methodologies, there are teams, that are really agile: They detect problems early, find solutions quickly, make fast progress and have great development skills. And there are teams that don’t care about their most obvious problems (while the tiny problems get lots of attention), that create 10 alibi unit test months after the actual code has been written and whenever they meet they call it “scrum” (short meeting) or “retrospective” (long meeting):
Cargo cult software engineering is easy to identify. Cargo cult software engineers justify their practices by saying, “We’ve always done it this way in the past,” or “our company standards require us to do it this way”—even when those ways make no sense. They refuse to acknowledge the tradeoffs involved in either process-oriented or commitment-oriented development. Both have strengths and weaknesses. When presented with more effective, new practices, cargo cult software engineers prefer to stay in their wooden huts of familiar, comfortable and-not-necessarily-effective work habits. “Doing the same thing again and again and expecting different results is a sign of insanity,” the old saying goes. It’s also a sign of cargo cult software engineering.
Steve McConnell, IEEE Software, March/April 2000
Another example are coding standards that pretend to increase the quality. To comment each and everything is a particularly popular convention, but there is no proof that this has any advantages when using modern high-level languages. In fact there are even obvious negative effects as described here:
I could list many more examples like the widespread expectation that an SQL database gets faster whenever you add an index (not true!). The effects of cargo cult management can be observed on the larger scale, when
- proprietary software companies are getting into trouble and then start to pretend they’re doing “open source” without understanding the concept of free software
- you see uninspired page layouts that are supposed to imitate the “Google experience”
- a company invests lots of money into a “social media strategy” and then fails to respond to the “social feedback” they get
- employees are forced to use Windows, because the management thinks this is “enterprise” software (“if it costs nothing, it can not be good“)
These kinds of things don’t happen in real sciences, because you can not use a wrong formula in mathematics and still get the right result. In physics, you can not describe experimental results with some random, imaginary theory. There are obvious constraints while the software business has only very few constraints. Indeed the unique value of software is that it can be changed easily and you can write similar applications in many different ways. This opens the door for all kinds of hypes and weird practices that might – or might not – lead to the desired results.