What the United States Camel Corps Taught Me About Software Engineering

Recently, I saw a cool featured article on Wikipedia: The United States Camel Corps. And as I was reading it, I was thinking to myself That's exactly how software engineers think as well!

Let me summarise the article first:

  • In the 1850s, the US Army decided to trial the use of camels in the South of America
  • At that time, they used horses and mules for transport.
  • Camels were brought in because it was believed they would be more sturdy in the tough desert conditions of Texas.

Did the experiment succeed?

  • The camels were sturdier than the mule and horses
  • On a few particularly journeys, when several mules died and those that survived were very distressed, the camels were okay
  • A camel was bitten by a  rattlesnake and still survived
  • Camels didn't need water on the journey, and would eat anything on the way, including a creole bush that no other animal would eat

So camels were super successful, right?

Nope. The army abandoned the project and sold all the camels at an auction. One reason was the Civil War started, interrupting the experiment. But I think a bigger reason is: The US Army was a mule and horses organisation, and camels were too different culturally to make the change, even if they were technically better.

And this leads us nicely to software.

Ooooh, but X is technically superior, so it will succeed

Every software debate is full about how X should succeed because it is technically superior.

  • Linux is technically superior to Windows! 1999, 2003, 2004, 2007, 2008, 2010, 2012.......2021 is finally the year of the Linux desktop!

People have been making fun of how useless Windows is, how we need to move to Linux for 20-30 years now, and yet, people stick to Windows because it works.

The tone has slightly improved over the years. I remember in the late 90s, when still a teenager, I made the mistake of asking in an online forum what the big deal about Linux was (as I had been hearing of it, but didn't know much of it). I still remember the insults 30 years later. And not one of those people actually told me why Linux was better. Wave hand in the air: But open source! M$ evilz!!

And then every few years, people would predict how Windows was finally going to die and burn in a fiery hell.

That said, in 2021 I did finally wipe my Windows laptop and install Linux Mint on it (and had been using a Mac for most tasks anyway).

But it wasn't the technical superiority of Linux that drew me, but more like Microsoft actively kicking me away. I was just pissed off at Microsoft's constant attempts to spy on me and force me to use a Windows login on my own local laptop, so they can spy on me online as well.

At this point, Windows became the hard to manage camel, and Linux the boring mule, so I switched.

Even in the Linux world, it's all like Bah! You use Ubuntu? Should be using Arch, dontcha know it's the superior choice?

  • Lisp / Haskell / Rust are superior to Java/C++

When I started programming, everyone on Hacker News/ Slashdot were on and one about how Lisp was superior, how you became a better programmer just by learning Lisp. As I wrote in a highly quoted and peer-reviewed technical paper, reading 50 shades of grey makes you a better programmer than learning Lisp.

Then the Lisp crowd moved to Haskell. For a time, everyone was shouting at how we need to learn Haskell because ooh, it's so elegant

And now the same crowd has moved to Rust. Rewrite it in Rust is the new religion of the same people.

And in spite of all the proselyting, most commercial projects are still written in Java/C++. These are the mules of the programming world– they might not be lah-di-dah perfect, but they work as expected and everyone is used to them.

  • Excel vs the World

Every few years, a startup comes up and says Excel is so 90s! We can do better

Seems they can't. Excel is good enough and just works. I could say the same for Jira, but insulting Jira haters and Rust fanbois in the same blog looks like a very dangerous thing to do, so I'll stop.

Seeing the pattern? It's not the "technically superior" solutions that win, but the good enough solutions that get the work done.

The job of the US army was to win wars; how they got their supplies (mules or camels) didn't matter as much.

The job of software is to solve business problems. If a boring and mathematically inelegant language can solve the problem, that's good enough.

Because let's be honest: Good enough solutions are, in most cases, good enough.

Hard core programmers love camels, but for the rest of us, mules are preferable. Camels may lead to a 10-20% improvement, but they lead to a lot of headaches managing them. Plus, camels expect you to change your whole setup just to work for them.

Remember, your goal is to move your cannons from A to B, and if mules work, use mules. Don't get drawn in by the attraction of prima donna Rust coders, sorry I meant camels.


Mules >> Camels