It looks like you are using Internet Explorer, which unfortunately is not supported. Please use a modern browser like Chrome, Firefox, Safari or Edge.

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

Publicerad i Teknologi

Skriven av

Petri Kainulainen
Software Architect

Petri Kainulainen is a software architect who has over 20 years of experience in different software development projects. He is interested in automated testing and is always looking for new ways to improve the ROI of writing automated tests. Petri has been writing technical articles for years; you'll find him at petrikainulainen.net.

Artikel

26 oktober 2022 · 6 min lästid

There are three main downfalls of cargo cult development, states Petri Kainulainen, Nitor’s Software Architect. Cargo cult encourages quick wins instead of creating sustainable code that withstands the test of time. In his first article of the series, Petri explains what are the downfalls of this approach and how to avoid them on your path to becoming a true professional.

What is cargo cult development? A cargo cult in software development takes two different forms:

  • If you write (or copy) code without understanding how it works or you cannot tell if the code is required to solve your problem, you are practicing cargo cult programming. For example, if you blindly copy code from Stack Overflow without understanding how the code works, you are guilty of cargo cult programming.

  • If you use design patterns or programming styles without thinking if they are useful or analyzing if they should be used to solve your problem, you are doing cargo cult design. For example, if every class you write implements an interface, you are guilty of cargo cult design.

In a nutshell: do you value short term benefits over the long term benefits?

Cargo cult development encourages you to get the job done as fast as possible instead of writing sustainable and efficient code that withstands the test of time. Also, cargo cult development will cause several problems which will hurt you, your colleagues, and your customer. 

Three common downfalls are:

1. Going for the trial and error method

First, because you do not understand how your code works, or cannot tell if it’s really required, you will struggle to write good code. Most likely you will end up using the so-called trial and error approach where you copy code samples found on the internet and tweak them until your code kind of works. This will result in the following:

  • Because you cannot identify the security risks of your code, you cannot minimise these risks. This naturally means that you cannot guarantee that your code is safe.

  • You cannot be sure that edge and corner cases are handled properly. For example, if an invalid input value is passed to your code, it might throw an exception instead of returning a validation error that describes the problem. In other words, your code is hard to use.

  • You do not know if your method is the best way to solve the problem in hand. Instead, you might use a suboptimal solution which is not fast enough or can cause problems in the future when the requirements change or the amount of processed data grows.

Although experimenting with code samples is quite common when you are learning new things, a wise developer will also figure out how and why the code works the way it does. 

2. Adding unnecessary complexity to your code

If you are guilty of cargo cult design, the odds are that you add unnecessary complexity to your code. For example:

  • If you use the “wrong” design pattern, the code which implements the required feature is most likely more complex than the code which implements the feature when you use the “correct” design pattern.

  • If you insist that every class must implement an interface, you will write code that’s hard to read. If your interface has only one implementation, it’s just unnecessary clutter that makes it slower to navigate to the implementation of that interface.

  • If you want to solve every problem by using functional programming, sometimes your code is much harder to read than the code which uses imperative programming. Although functional programming has its benefits, I have personally witnessed a situation where a developer had to rewrite one’s code which had an if-else statement because the reviewer was a functional programming aficionado. Unfortunately, the “fixed” code was much harder to read than the original code.

I think that the goal of every developer should be to write simple code. This is hard because writing simple and clean code requires experience on making the right tradeoffs. However, it’s the best choice in the long run because writing complex code will cost both time and money in the future when someone, perhaps even you, has to maintain your code.

3. You won’t grow as a professional

Cargo cult may not only be something that hurts your projects, but you will damage your own career because:

  • You might be so afraid of peer review that you try to avoid it at all costs. For example, creating a pull request can be a paralyzing experience. It’s because you know that you might not be able to answer the questions asked by your colleagues, and most likely cannot fix the code if your colleague asks you to make some changes to your pull request. Sadly, if your employer requires peer reviews (as most do nowadays), procrastination prevents you from finishing your tasks as fast as possible.

  • You won’t learn and grow as a software developer. If you want to learn new things, you must first understand the basics before you can move on to more advanced topics. If you have enough motivation and you accept that there are no shortcuts, you might finally reach the level where you can call yourself an expert. This might sound like an elitist and arrogant attitude, but the sad reality is that if you aren’t willing to understand how and why your code works, you will never be an expert.

  • You might become an expert beginner. If your employer appreciates the “we will fix it later” mentality, you are most likely rewarded for your work. Although it’s great to get a raise or feel appreciated because of your work, in this case, the feeling is a double-edged sword. You might think that you are a skilled software developer, but this illusion will shatter immediately, if you apply for a position in another company. For example, you might not get the job because your skills aren’t good enough or your salary expectation is too high (when taking your skills into account). If you end up in this situation, you don’t have a lot of good options. You can either continue working in your old job and hope that they don’t lay you off, or be humble and start improving your skills from the ground up. The downside of the latter option is that it requires time you might not have.

Professional growth often is, by definition, a rocky road. It needs stamina, ability to be uncomfortable at times and perseverance not to give up when you hit a dead-end.

Cargo cult is a short-term solution to a feeling of uneasiness that is an innate part of professional growth. Avoiding that temptation not only makes you a better professional but will also result in personal integrity that sets your client’s best as a priority, helping them achieve the results they want.

There are both personal and organisational reasons, which I will cover in my next blog, for why cargo cult with all its downfalls may seem like a good option. Taking the longer road, however, is the way to becoming a solid software development professional – one that clients will count on in the years to come.

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


Skriven av

Petri Kainulainen
Software Architect

Petri Kainulainen is a software architect who has over 20 years of experience in different software development projects. He is interested in automated testing and is always looking for new ways to improve the ROI of writing automated tests. Petri has been writing technical articles for years; you'll find him at petrikainulainen.net.