Raimund Krämer

The phenomenon of cargo cult is very common in the software industry. With this article I want to raise awareness for the problem of cargo cult and provide some examples of topics that are (in my experience) especially prone to it.

The goal here is not to educate about those specific topics. My main point is that you can hear a term being misunderstood and misused a hundred times by different people and you’ll probably think it is the actual meaning. Or you see certain practices or processes being followed in different companies for years or decades with nobody questioning them, because everyone else has seen the same practices at their previous jobs as well without ever understanding the reasoning behind them. Often misinformation and myths spread faster than education. Maybe you will recognize in some of the examples that you have been mislead so far, through no fault of your own. You might then want to look them up and then apply the same principle to other things you may have taken for granted so far. Questioning established processes and practices and educating about misconceptions and cargo cult is a marathon and our shared responsibility. Remember to ask “why”!

Examples

CI/CD

Continuous integration and continuous delivery (CI/CD) are not primarily about having a build/test/deployment pipeline. If that surprises you, you might want to read up on the practices (!) of continuous integration and continuous delivery.

The “3 questions” of the daily stand-up

“What have you done yesterday, what are you going to do today, and are there any blockers?” These 3 questions are often used in Scrum during the daily stand-up. This results in everyone simply giving a status update and kills any actual collaboration between the team members. The 3 questions have been discouraged for years by the creators of Scrum since they have been completely misunderstood and misused. Still, they are taught to newcomers to the field as a “best practice” by those who haven’t questioned an outdated practice and have been reinforced by others doing the same.

Story points

Ron Jeffries famously apologized for inventing story points, because the way they are often used is an anti-pattern for holding people to a rough estimate in a complex field of work, converting them to units of time, or using “velocity” as a target. They were intended to be more abstract than estimating work in hours or days for efforts that are difficult to predict, and yet some people go as far as dropping story points in favor of estimating hours again. Sometimes arguing that they are “the same anyway, but easier to grasp”.

Refactoring

The concept is very simple: Refactoring means changing the structure of code without changing its (externally observable) behavior. And yet, the term is often used to refer to any changes of existing code.

Clean code

Referring to code as “clean” is a colloquial way of expressing that it is simple, easy to understand, easy to use, and easy to change. Some people, however, use the term strictly in the spirit of the “Clean Code” book, which is not without controversy for its dogmatic and opinionated, in some cases outdated advice. While I personally think that “Clean Code” is a decent book, especially if it is not the only source one uses for learning how to write cleaner code, it has not invented the term, nor is it a rule book. It is simply one of many sources of inspiration and opinions.

DRY

“Don’t repeat yourself”, one of the classic pieces of advice from “The Pragmatic Programmer”. If applied well, it makes code easier to maintain. Unfortunately it has been misinterpreted and many programmers use it to couple together pieces of unrelated code by reusing similar code snippets. The authors have clarified the intended interpretation (reducing duplication of knowledge/information, not of code) in the 2nd edition of the book, but developers still learn the wrong interpretation from other developers and make code harder to maintain by “reusing” code in unrelated modules.

The SOLID principles

Misunderstood more often than not and treated as gospel by some, these design principles are intended to help create more maintainable software. Some wrongly equate them with “clean code”, others spread misguided two-sentence summaries in social media posts. Most developers have heard of them, few can define them, far fewer can define them correctly. Those in the second category often see them as very important, even when their interpretation is explicitly mentioned by the author who coined the acronym as a common misinterpretation that leads to worse software designs. They are not the definition of good software design, although they can be helpful if understood well. Many more design principles and alternative principles and acronyms exist, many of which are easier to understand and less often misinterpreted.

GitFlow

It may have been a decent idea back in 2010 when this branching model was invented. Git itself was very new back then, having existed for just a few years at the time. After the author has found some success with this branching model in his projects, he described it in a blog post, which lead to wide-spread adoption and turned it into a quasi-standard. So far so good. The problem: It is still, today and in recent years, being considered and taught by some as a “best practice”, often because it is only compared to the alternative of “no standard approach to branching”, and so having any standard seems like a good idea. The author has amended the original post in 2020 (10 years after the blog post was originally published), recommending alternative and simpler approaches. The software industry in general has changed a lot, at least on average in some areas (we are still talking about cargo cult after all and some teams or companies seem to stay stuck in their ways for a long time). Better, simpler branching models have been adopted. A lot of software has shifted to being distributed via web or downloads (e.g., mobile app stores), compared to packaged software on CD-ROMs with infrequent releases. CI/CD and DevOps have been popularized (with the caveat of, well, being widely misinterpreted and wrapped onto existing processes and habits). GitFlow is interesting from a historical perspective, but has been far from a “best practice” for at least a decade. Of course those who still swear by it think that their situation is special and that GitFlow solves problems for them.