Minimise the risk of cargo cult development – three tips on how team leaders can build a cult-resilient environment

In this article series, Petri Kainulainen covers cargo cult development in different aspects. Previous articles:

1. How are cargo cults born and how to resist temptation of quick fixes

2. Why do developers want to hurt themselves with cargo cult development

When you are running a software development team, you want your team to deliver features that are secure, work as expected, and don’t cause problems in the future. To meet these goals, make sure your developers aren’t doing cargo cult development. 

Here are three steps you can take that help reduce the probability of cargo cult development in your organisation. 

1. Build a culture where it’s required to ask why

When your developers think it’s fine not to understand how and why their code works, they are doing cargo cult development. 

Challenge this mindset by building a culture that encourages critical thinking. Getting started is simple: just encourage everyone to ask the question why. If used properly, this question is an extremely powerful tool that can help you reduce or even eliminate cargo cult development.  

Ask hard questions and challenge assumptions during onboarding

Encourage new employees to ask hard questions and challenge assumptions during onboarding. By constantly challenging design decisions, they gradually become familiar with the code base, understand why the code works the way it does, and can identify the different tradeoffs made during development. The best part: these employees learn to embrace critical thinking – the arch enemy of cargo cult development – and thus steer clear of practising it. 

Embrace critical thinking and challenge best practices

Software development has many best practices which are useful when a developer is solving a very specific problem. Unfortunately, many software developers are obsessed with best practices and use them in every situation without paying any attention to whether the practice is useful in the current context. These developers have abandoned critical thinking and replaced it with blind faith in best practices. This, ironically, is a common cause of cargo cult development.

To ensure that this doesn’t happen on your watch, build a culture that challenges everything, including so called best practices. Ensure your developers understand you don’t want them to follow best practices if they don’t help them to write better code. Challenge your developers to make educated decisions instead of blindly following best practices.

Review all code before it’s merged into the main branch

One simple way to reduce cargo cult development is to ensure that all code is reviewed and accepted by at least X team members (pick a number that works for you) before it’s merged into the main branch. This reduces cargo cult development because:

• Team members should challenge the design decisions found from the pull request (PR). As a result your developers are less likely to write code that they cannot understand.

• People polish their code, i.e. try to write clean, easy to understand code, before they create a PR. 

• Those who review the PR ensure that the reviewed code isn’t merged into the main branch, if they don’t understand how it works.

For the review process to work, make sure that your company culture encourages frank but respectful feedback that centres on the topic and is not personal. The point is to discuss code, not whether the person who wrote the code is skilled. By keeping the critique constructive and strictly about code, the improvements and/or corrections are taken the right way – as a team effort to ensure the highest quality design possible.

2. Keep your technology stack relevant and up-to-date

If your technology stack is not up-to-date you may have trouble recruiting top talents. Another stumbling block are frameworks that are not used anywhere else. Developers value transferable skills: few people want to learn obsolete tricks that they cannot use anywhere else. To create an environment that encourages professional development, take note of the following:

Avoid inhouse frameworks

There was a time when it made sense to write in-house frameworks as it was the only way to provide reusable solutions to cross-functional concerns such as transaction management and authorisation. Nowadays, however, the open-source community has written many frameworks that provide solutions for cross-functional concerns. 

As in-house frameworks are built by a small group of key individuals, these people are the only ones who know how to use the framework. This a problem because:

• In-house frameworks don’t survive organisational changes and employee turnover. Every time you lose a key individual, you will lose information that isn’t easy to replace. If you cannot replace the lost information, you will eventually end up in a situation where developers can implement new features, but no one really knows how the in-house framework works.

• Since developers cannot find help from the internet, the problem-solving process depends on the contribution of the individuals who wrote the framework. These people might not always be available and as developers have a schedule to meet, developers will likely keep experimenting until they have code that sort of works.

• The new developers cannot leverage their experience from other widely used frameworks and concentrate only on code that solves business problems. Instead, they have to start from scratch and investigate how your framework solves cross-cutting concerns. To make matters worse, the odds are that the new hires won’t get enough support from the key contributors who know how the framework works.

• It’s quite rare that a developer spends their entire career in one company. That’s why most developers favour positions that allow them to learn skills they can use later in their careers when working for someone else. If your framework isn’t used anywhere else, most developers have no incentive to learn your framework and fall back on cargo cult development. 

To summarise, if you use an in-house framework, it’s common that your developers end up in a situation where doing cargo cult development is the only way to ship the implemented feature on schedule. 

Keep your technology stack up-to-date

An outdated or obsolete technology stack places you in a worse situation than a company that wrote its own in-house framework because you don’t have developers who are 100 percent sure how the framework should be used. Instead, the developers have to rely on external sources (such as StackOverflow, blogs, Youtube, and different courses) when trying to learn your technology stack or solve problems found in the code.

The problem is that finding useful resources becomes harder when your technology stack becomes older. Because the demand for new stuff is typically higher than for old stuff, creators tend to create material that uses the newest possible versions. New resources are also likely more relevant than old ones, so search engines such as Google and StackOverflow tend to bury the material about outdated or obsolete versions. Thus, you become dependent on a few key individuals who know how your technology stack works and will face the same challenges as a company which uses an in-house framework.

That being said, you shouldn’t go all-in either. Often it’s wise to use a mature technology stack that’s still under active development. Remember that if you use a bleeding edge technology, you are taking a big risk because you cannot know if the technology will be a success or a failure. 

Leverage synergy benefits when you are making technology selection

If you have to manage multiple software development projects that deliver similar applications (e.g. a web application), consider using the same or similar technology stack in both projects. If more developers use the same technologies, they can help each other when someone runs into a problem. Also, this allows you to move developers between different projects without a long onboarding phase that increases the risk of cargo cult development.

Don’t be afraid to use new technologies if using them has more pros than cons. If you play it safe long enough, you will end up with an outdated technology stack, increasing the risk of cargo cult development.

3.  Ensure and enable knowledge-sharing 

Developers often have tight schedules so it’s crucial they have access to information that helps them deliver the implemented feature in time. That’s why you should build a culture which encourages everyone to share their knowledge with their colleagues. You can do this by:

Use code reviews as a knowledge-sharing tool

Code reviews are sometimes seen as a quality assurance tool, but the primary function of code review is to share knowledge. The developers who review the code will understand how the code works and why the reviewed code was designed and written in a specific way. Also, after the code review is over, the developer who wrote the reviewed code should be able to identify alternative solutions to the solved problem and be more familiar with the codebase. This will reduce the possibility of cargo cult development.

Keep technical documentation thin and up-to-date

Developers are often forced to write comprehensive technical documentation that quickly becomes obsolete as keeping it up-to-date takes too much time and effort. You might have multiple outdated versions of the same document which were born when two (or more) developers solved the same problem in a bit different way – like installing a development environment to Windows vs MacOS.

This situation is both confusing and frustrating because developers cannot find the information that helps them to solve problems. This increases the risk of cargo cult development because, typically, developers will end up trying different things until their code works. To make matters worse, developers cannot be sure why their code works because they tried multiple different things.

That’s why you should:

• Minimise the amount of technical documentation written by developers. Ensure that everyone knows where the documents are located, and that developers will go through the technical documentation periodically and update or delete outdated documents.

• Remember that shared responsibility is no one’s responsibility. 

Have an async way of asking for help

Developers don’t like to be interrupted when they are in the flow. This doesn’t mean that they don’t want to help other developers. They just feel that the price of helping another developer is too high. Conversely, developers are willing to help, if they can choose when to do it. Make sure that you have an async way of asking for help (such as Slack) and encourage everyone to use it. 

Ensure everyone has time to help

If you want people to share their knowledge and help each other, you must ensure they have time to do it. This means that your developers cannot spend 100% of their time working on their own tasks. Instead, make sure that developer’s don’t have too tight schedules and ensure that your developers understand that you expect them to use the extra time for sharing knowledge and helping other developers.

It is not rocket science to build a culture where the temptation is minimal to fall back on cargo-cult development, but it requires diligence and conscious leadership efforts. 

Long story short:

1. Build a culture where it’s required to ask why

2. Keep your technology stack relevant and up-to-date

3. Ensure and enable knowledge-sharing 

In this article series, Petri dives deep into cargo cult development, covering employer, developer and customer perspectives. In the upcoming articles, Petri gives insights into cargo cults from a developers’ point of view and gives tips on how employers can avoid cargo cult culture.