We tend to think about software development as a very special & unique "discipline", positioned somewhere in the middle between science, engineering, craft, even art. And in the end we keep finding out that the same patterns & behaviours we observe everywhere else, apply in software development as well. One of the truly interesting (& to some degree - surprising) cases is ...
What is cargo cult? In short words it means mindlessly copying elements (without true understanding of their role) of existing solutions (usually not our ones) in belief, that what we'll shape that way will have inherent (& desired) characteristics of the original product(s).
Originally, it looked like that:
"In the South Seas there is a cargo cult of people. During the war they saw airplanes land with lots of good materials, and they want the same thing to happen now. So they've arranged to imitate things like runways, to put fires along the sides of the runways, to make a wooden hut for a man to sit in, with two wooden pieces on his head like headphones and bars of bamboo sticking out like antennas—he's the controller—and they wait for the airplanes to land.
They're doing everything right. The form is perfect. It looks exactly the way it looked before. But it doesn't work. No airplanes land. So I call these things cargo cult science, because they follow all the apparent precepts and forms of scientific investigation, but they're missing something essential, because the planes don't land."
(src: Richard Feynman)
And how does it apply to software development? Twofold.
The first case is what we sometimes call Stack Overflow syndrome. People give up on thoroughly comprehending the library / framework / platform they use & just copy code samples from tutorials / samples / SO answers. They don't really understand what the code does, but they assume that if it was put in the original place, it just has to be there & it will provide all the necessary qualities.
The seconds case is about picking / replacing the technology used - people omit either identifying their actual needs or recognising the real problem they are struggling with and try to fix the situation with picking some hyped technology, because some Silicon Valley unicorns use it or it gains recently a lot of attention in the Internet. "If it worked for Facebook, it should work for us!" & "John Doe has written 3 blog posts about that, there was also a podcast and a recent conference speech ..." seem for them like a legit justification for quite serious technical decision.
There's no magic in IT
Do these look similar to the Feynman's observations? I think so. And (what is more important) it has the same root cause: ignorance & gullibility. How so?
- new, shiny tech looks very appealing when we learn the basics - but when we encounter actual problems (that require diving deeper & sometimes crossing the boundaries of our comfort zone) we forget about the initial impression, give up solving the actual issue (sometimes even on identifying the real issue!) & ... tend to switch to the newest "king of the sandbox".
- I knew teams who were very poor skill-wise & self-deluded enough to not realise it at all - in their cases technology swap was pretty regular: they've always blamed tech, tools, method (for fucking up, being slow or bogged down) while actually they just sucked in terms of overall delivery & had not clue (or will) to improve. In their opinion once they get a proper framework/platform/language in hands, success is imminent.
The remedy is to ... pardon the statement ... show some balls, set your shoulder to the wheel & solve the problems, instead of hoping the technology itself will do it in some magical way.
If you're struggling with Tech A, don't just assume that Tech A has to suck then. Instead, ask yourself few questions:
- are you solving the correct problem?
- do you know what's the actual problem?
- do you understand how this stuff works (is supposed to work)?
- did you put enough effort to gain this understanding?
- are your actions really aimed to solve this problem or are you mindlessly copying things from the Internet in hope something will work?
They differ - that's correct, they have particular flaws, some things can be easier done here or there - but in general this choice really barely matters - you can implement an equivalent solution with each of them! What truly matters are: skill, professionalism, willingness to learn, ability to co-operate, alignment on goals, commitment for the solution & decisions taken - HUMAN factors.