Cargo-cult programming
Some great reminders to folks about cargo-cult programming by Eric Lippert. This concept was taught to me in college, I think in a CST115 class. Boy is it the truth. Sometimes programmers try to make excuses for not understanding the how - "I don't need to understand SOAP, I'm not a plumber." Well, I'm not a professional plumber either, but I do own a copy of the Consumer Reports "How to fix anything in your house." Does that make me a plumber? Hardly. Just a guy who knows that water flows through pipes. If not, I'm just an amazed townie who thanks the magical water gods when I get hot and cold running water upstairs.
During the Second World War, the Americans set up airstrips on various tiny islands in the Pacific. After the war was over and the Americans went home, the natives did a perfectly sensible thing -- they dressed themselves up as ground traffic controllers and waved those sticks around. They mistook cause and effect -- they assumed that the guys waving the sticks were the ones making the planes full of supplies appear, and that if only they could get it right, they could pull the same trick. From our perspective, we know that it's the other way around -- the guys with the sticks are there because the planes need them to land. No planes, no guys.
The cargo cultists had the unimportant surface elements right, but did not see enough of the whole picture to succeed. They understood the form but not the content. There are lots of cargo cult programmers -- programmers who understand what the code does, but not how it does it. Therefore, they cannot make meaningful changes to the program. They tend to proceed by making random changes, testing, and changing again until they manage to come up with something that works.
Read the three-part (and counting) series here: Part 1 Part 2 Part 3 [Brain.Save()]
All this talk about cargo-cults and Mort/Elvis/Einstein reminds me of the Programming by Coincidence stories.
Do you ever watch old black-and-white war movies? The weary soldier advances cautiously out of the brush. There's a clearing ahead: are there any land mines, or is it safe to cross? There aren't any indications that it's a minefield---no signs, barbed wire, or craters. The soldier pokes the ground ahead of him with his bayonet and winces, expecting an explosion. There isn't one. So he proceeds painstakingly through the field for a while, prodding and poking as he goes. Eventually, convinced that the field is safe, he straightens up and marches proudly forward, only to be blown to pieces.
The soldier's initial probes for mines revealed nothing, but this was merely lucky. He was led to a false conclusion---with disastrous results. [The Pragmatic Programmers]
Being a Mort or an Einstein isn't about VB.NET vs. C#. It isn't even about VB6 programmers without CS degrees. It's about caring how code works. Not just for caring's sake (although it helps) but because it makes you a better, more well rounded, and ultimately effective programmer. So, here's MY cargo-cult-programming-by-coincidence story:
My sister in law immigrated here from Zimbabwe. She's a teacher, in her thirties, but had never driven. So, we took the Prius over to the parking lot and practiced for days. We finally got to parallel parking, and she just wasn't getting it. It just didn't make sense to her. So I said, "imagine how the front tires turn left and right when you turn the steering wheel."
"The front?" she said. "What difference does it make?" Turns out she didn't realize that the front tires were the ones that turned. She'd imagined ALL FOUR tires turning left and right when the car turns. I insisted that, no, on cars, it's just the front wheels that turn. She didn't believe me until she got OUT of the car, and watched me parallel park. She was utterly amazed that the back tires stayed straight and followed the front ones.
"You didn't know this?" I asked. She said "I never gave it any thought. I assumed they all turned, and never asked the question again."
Certainly this assumption became a problem when trying to 'debug' the process of parallel parking.
About Scott
Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.
About Newsletter
Anyway, early 1990's Acura (Honda) Preludes had (active) 4 wheel steering. They would turn one way below 30mph and turn the other way above 30 mph. Try explaining that to your sister in law!
Comments are closed.
Your sister in law shouldn't have to understand how the internal combustion engine works in order to parallel park.
Abstraction is our friend when everything just works.
Abstraction is our enemy when it doesn't.
About the "how" - there's SO much information on how to do something. There's much less on where you should do it - where it fits in the big picture, and how the big picture must change as a result of the "where" decision. And finally, the "why" is the most elusive.
Should you ask the average programmer why they use a layered architecture, most will talk about some *abilities. However, when you ask how the layered architecture helps in terms of each specific one, rather few will be able to give a good answer. I recently witnessed this at a local .Net user group.
To sum up, I think that we can all agree on this:
I don't have to be a professional plumber ( writing up the WS specs ) to use the pipes for my needs. But, when the pipes get clogged, I'll open up my copy of "How to fix anything in your house" and muddle through. Once I get things working again, I can turn my attention back to what I do best - deliver value to my customers.