The term ‘cargo cult’ harks back to the behaviour of South Pacific islanders during World War II who, upon observing airdropped cargo supplies, attempted to replicate the observed behaviour, hoping to attract the same bounty. When applied to software development, it refers to teams that mimic successful practices or methodologies without understanding their purpose or context, leading to a superficial implementation that lacks the efficacy of the original.
My experiences with cargo cult software development
Throughout my time in the software development industry, I’ve witnessed teams who religiously adopt methodologies from tech giants like Google or Spotify, hoping to capture a fraction of their success. They would implement Google’s engineering practices or Spotify’s squad model without considering the vast differences in scale, culture, and business needs. This approach often results in frustration and disillusionment when the anticipated benefits fail to materialise.
It’s crucial to recognise that not every organisation operates on the same scale or has the same resources as these behemoths. For instance, a medium-sized enterprise trying to replicate Spotify’s autonomous squads might struggle without the underlying culture of trust and mature DevOps landscape that Spotify cultivates.
This imitation extends to tooling as well. It’s not uncommon to see a team opt for a distributed microservices architecture using Kubernetes, simply because it’s a trend among leading tech companies, ignoring the overhead and complexity it introduces. This can lead to a scenario where the team is grappling with the operational challenges of a distributed system when a simpler monolithic architecture would have sufficed.
Another example is the blind adoption of the ‘move fast and break things’ mantra. What works for Facebook, with its vast engineering team and robust infrastructure, may prove catastrophic for a business with a smaller user base and limited resources to manage potential fallout from rapid, unchecked changes.
These experiences underscore that software development is not just about the process, but also about the context and understanding. True process adoption is characterised by a deep understanding of its principles and a thoughtful implementation that considers the team’s unique context. In contrast, cargo culting focuses on replication at the expense of understanding, leading to a rigid and ineffective implementation of processes.
How to recognise and avoid cargo culting
Recognising cargo culting can be as simple as asking ‘why’. Why do we follow this particular process? Why do we use this tool or method? If the answer is ‘because that’s what the successful team does’, rather than an explanation linked to your specific needs, you may be dealing with a cargo cult.
In the context of the Software Development Lifecycle (SDLC), asking ‘why’ becomes a powerful tool for introspection and improvement. For example, consider a team that adopts a particular agile methodology, such as Scrum or Kanban, simply because they’ve heard it works well for other successful teams. They might start holding daily stand-up meetings or creating Kanban boards without fully understanding the reasons behind these practices.
To identify cargo culting, one can scrutinise various aspects of the SDLC:
Design patterns
Using complex design patterns inappropriately or as a one-size-fits-all solution, without stopping to consider if they are the right fit for the problem at hand, can lead to over-engineering.
Code reviews
Conducting code reviews because it’s a checkbox in the process, not because it’s an opportunity to share knowledge and improve code quality, indicates a lack of understanding.
Agile methodologies
Adopting complex project management techniques without the corresponding project scale or team size, leads to cumbersome over-management.
Microservices
Switching to a microservices architecture and using Kubernetes like Netflix, without considering if our application’s complexity and team’s operational knowledge warrant such an infrastructure.
Squad models
Copying Spotify’s squad model, hoping to foster innovation, but without the supporting culture of autonomy and the scale at which such a model becomes beneficial.
Continuous integration / Continuous Deployment (CI/CD)
Implementing CI/CD pipelines because it’s a current industry standard, without appreciating how it can streamline the development process and reduce integration issues.
Continuous delivery
Implementing continuous delivery because Amazon deploys every second, ignoring that our own business might not need such frequent deployments and could instead benefit from a more tailored cadence.
Testing
Investing in an extensive testing infrastructure that doesn’t match our immediate needs or available resources.
Avoiding cargo culting begins with education. The antidote to cargo culting is a culture of curiosity and learning. Teams should strive to understand the principles behind the practices they adopt. Communication is key – ask questions, discuss practices, and ensure the whole team understands ‘why’. Teams should be encouraged to understand the principles behind their tools and practices. They should be asking questions like:
- Does this process help us achieve our specific goals?
- How does this tool or method contribute to the efficiency and quality of our work?
- Are there alternatives that better suit our unique challenges and context?
By fostering this mindset, teams can avoid the pitfalls of cargo culting and instead adopt practices that truly align with their objectives, leading to more efficient and successful software development.
Above all, remember that software development processes should be adapted to your unique context and not dogmatically followed without understanding.
Conclusion
Cargo culting in software development serves as a cautionary tale reminding us of the importance of understanding over imitation. As we navigate our software development journey, let’s strive to critically evaluate our practices, embrace thoughtful process adoption, and resist the allure of the cargo cult. Remember, the goal of adopting a software development process is not to follow a process verbatim, but to facilitate value delivery – and that, dear reader, cannot be achieved through mere mimicry. It requires understanding, adaptation, and continuous improvement.
Author: Martin Závrbský