The Cargo Cult (for those who haven’t heard of it) is an incredibly fascinating phenomenon.
Most widely known during and after World War II, Cargo Cults are the result of tribes on remote islands coming in contact with military occupation. Planes would come out of the sky and land nearby, containing food, weapons and supplies. The soldiers would share the food with the tribes and thusly, the tribe would associate food and supplies with the planes but they didn’t understand where and how the planes arrived. Once the war was over and the troops pulled out and dismantled the towers, etc, the tribes would erect their own crude towers and mimic the soldiers directing the plane landings in hopes of more food coming out of the sky. They wanted the effect, but didn’t understand the cause.
Well, let me tell you, brother…there are far too many “Me too!” software companies that behave like Cargo Cults.
“I keep making cool apps, but billions of dollars never seem to fall out of the sky. I even wear turtlenecks, drive a Tesla, and I’ve read 7 Habits of Highly Effective People so many times I have it memorized.”
Ok, maybe I’m paraphrasing (or projecting…HA!). I’ve been lucky enough to have hired several GREAT developers and 2 of them have never taken a single programming class, and both are musicians (Sound familiar?). I’ve also worked with developers who have absolutely zero concept of the “WHY?” portion of problem-solving.
Obviously, requirements are critical for virtually all software projects. I’m not against them. What I AM against, however, is when you force an idea person (whether technical or not) to become an expert and practically write the code for you. Don’t just stand there at the end of the abandoned runway and wave your arms like you’ve seen the other guy do. I’d hazard a guess that the vast majority of code in production in the last 10 years was copied and pasted from a a Stack Overflow article somebody found by doing a google search for a simple solution to the problem they should be able to solve without using Google as their pacifier.
Most of the projects I take on require as much listening and proper explaining as they do coding and testing. True innovation is derived from a solid UNDERSTANDING of why you’re solving a problem as much as the code that solves it. Not sure why so many developers notoriously hate explaining things. Code reviews and daily standups are supposed to help that problem, but I’ve yet to see it make a large positive impact. The faster you get over your Fraud Complex, the better you will be at explaining and, subsequently, understanding your solution. No more waving at the sky waiting for billions of dollars to rain down on you.