Ever heard of a cargo cult? It’s a term describing the philosophy of many pre-industrial tribes in the Pacific during World War II with respect to the “cargo”; i.e. the foodstuffs and equipment called in by American and Japanese radio operators. The thinking went that the Americans and Japanese had appropriated (stolen) the cargo that rightfully belonged to the natives by means of liaising with the gods.

The interesting thing isn’t the belief that the cargo was stolen but more that the means of stealing it back were novel. The natives began to imitate the radio operators in the hope that building the same items of worship (realistic-looking radio sets, landing strips and in some cases even mock aircraft), and memorising the noises that the operators made and faithfully reproducing them, would help them divert the cargo back to its rightful recipients.

Go on. Laugh. Laugh rudely and insensitively at the primitive natives. How could they be so naïve?

So what on earth does this have to do with software? Well, take a look around at most software projects you’ve been involved in. Why do we have multiple web service layers? Why do we separate concerns? Why do we abstract our persistence? Why even is a microservice?

There are legitimate (and good) answers to these questions, but the most common one is “because everyone else does it.” In other words, other people do these things and receive good software (“cargo”) in return, so if we do it then perhaps we’ll receive the cargo instead. The key is that some people understand why they do it, and some people just mimic it.

This post was prompted by a recent experience in which I ended up tearing apart an entire application (data access layer, service layer to access data, business logic layer, view/presenter layer etc.) and rebuilding it with something sensible - and all because someone tried to do it right and sadly had no idea how to do it.

I’ve seen so many software projects started with the absolute best of intentions. In most cases I honestly can’t fault the effort or the diligence displayed by the original developers - after all, almost nobody deliberately sets out to do a poor job. It’s heartbreaking, for example, to see someone having spent weeks or even months of their life inserting a web service layer for data access without understanding why they’re doing it, then complaining that their app’s too slow because every action ends up requiring a full table to be fetched and serialized over a SOAP call. Equally, I’ve seen people follow the Single Responsibility Principle to a ridiculous extent but end up with utterly unmaintainable code because they didn’t properly understand why it’s important. MVC, MVVM, n-tier… they’re all useful tools in the box, but all too often they’re just fake radio sets made of wood or landing lights that don’t emit light.

Having earlier laughed rudely at the primitive natives, let’s now cry. Cry, because you know that, at least once, each of us has been guilty of the same lack of understanding. Each of us has done something “because it’s best practice” and each of us has subsequently realised our own error.

Finally, to stand on my fake soapbox for a second: go and teach your craft, so that other people don’t have to make the errors in the first place, and so that you don’t have to clean up messes like these and destroy someone’s prized wooden radio set while you’re at it.

P.S. Credit to my friend and colleague, Paul Stovell, whose tweet finally prompted me to finish and publish this blog post.