Cargo Cult Thinking

In the South Seas there is a cargo cult of people. During the war they saw airplanes with lots of good materials, and they want the same thing to happen now. So they’ve arranged to make 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 for 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.
— Richard Feynman

 

Many of the problems shared by business management and software engineering I mentioned in the previous post stem from Cargo Cult Thinking. As mentioned by noted physicist Richard Feynman in his famous speech to CalTech students that even in these modern times, people resort to blindly following how other people do things in the hopes of reaping the same results.

Dr. Feynman used cargo cults to criticize how many scientists fail to follow the scientific method by merely going through the steps of experimentation but not making sure that their process is scientifically sound. The Halo Effect uses cargo cults in the same manner by exposing the mistakes made by best selling management books in their research. The book basically tells the reader to ignore all those pages detailing how the latter conducted its research because no matter how “rigorous” they were conducted, they were never sound to begin with i.e. there were critical flaws in their process from the start.

Cargo cult thinking in the field of software engineering doesn’t even bother with claiming to follow the scientific method. As Steve McConnell writes in his “From the Editor” article in IEEE Software, March/April 2000, some managers are deluded to think that simply following the culture of highly successful companies will result in radical improvements in productivity. On the smaller scale, many novice programmers (and sadly, software teams in general) are deluded to follow cargo cult programming practices without even knowing why they are used successfully by other coders in the first place.

In my opinion, cargo cult thinking isn’t that bad… if only one or two people are affected. As they usually fail in a spectacular fashion, they make the affected people think twice before doing something like that again. If an entire group, or worse, an entire company is blindly following cargo cult thinking… well… either you ramp up your risk management or you start making popcorn for the drama that will unfold. :D

Business Management and SE

Yesterday I was bored and uninspired. To make up for it, I went to Makati today with a simple plan in mind: find a good book and read a couple of chapters over a large cup of green tea latte.

There were a couple of good books in National Bookstore Glorietta 5 and Powerbooks Greenbelt 4, but Fully Booked Greenbelt 5 had both a 20% off on all books and a Starbucks bar(?) inside their store so I ended up with FB. The problem with FB was that they didn’t have the books I wanted to read, How to Win Friends and Influence People and The Millionaire Next Door, both Personal MBA books (with so many flashy business books in bookstores nowadays, that list serves as an easy way to separate the chaff from the wheat).

I was supposed to go for some random “bestseller” business book when I saw hidden in a corner (literally) The Halo Effect. The first thing that popped into my head was:

Personal MBA tells me that this is the only book worth buying here, so I might as well buy it.

And so I picked up the book, and immediately brought it to the counter to pay for it. Then I went over to Starbucks, ordered my latte, and started reading the book. A few chapters later, I was telling myself:

Good thing I trusted Personal MBA.

The Halo Effect has a simple message, namely, be skeptical about management bestsellers. But the reasons the book presents as well as the implications of the message covers a broad range of issues, and so I can’t talk about all of them in a single post. Now that’s good for me because I have enough material from a single book for at least 5 more posts. :D

Anyway, I won’t be tackling the book’s message in this post. I’ll just talk about something interesting from the first few pages of the book.

Continue reading “Business Management and SE”

The Complicator's Gloves

Here’s another story that I re-posted somewhere else before: The Complicator’s Gloves.

Good software is constantly under attack on several fronts. First, there are The Amateurs who somehow manage to land that hefty contract despite having only finished “Programming for Dummies” the night before. Then there are The Career Amateurs who, having found success after that first contract (read: taking the client’s money and not being sued for developing a useless product), actually manage to make a career out of repeating that experience. And then there are The Complicators, the side that tempts the best of us to join their ranks, even if only for project or two.

There are some so deeply embedded within The Complicators, that they’ve acquired a sort of sixth-sense: the ability to find meta-problems (“a problem with the process of creating a solution for the actual problem”) in virtually any solution. As we’ve all seen, the systems that these developers create often end up as a barely functional application comprised of a Matryoshka-doll-like nesting of problems and solutions. Given the chance to solve problems outside of Information Technology, I’ve often wondered how The Complicators might respond. Fortunately, Mike has given us that opportunity …

 

As programmers, we usually have multiple ways to solve problems. As computer scientists, we are aware that we must determine which of those solutions are elegant solutions. Unfortunately, due to our flawed educational backgrounds and personal experiences, our definition of “elegant” is usually “overcomplicated solutions” or “our solutions” (or both).

As software engineers, we must unlearn that potentially dangerous way of thinking. Elegance for us should always begin with simplicity.

So the next someone suggests a complicated solution for a simple problem, always keep in mind that that problem might be solved by “gloves”. (Unless, of course, you’re not going to be affected by that complicated solution. :D )

Zed Shaw – The ACL is Dead

I wasn’t able to post one daily entry yesterday because the net connection was down at Lex and Flori’s place. Here’s the make up post.

Steak and strippers, baby!

I wasn’t able to post one daily entry yesterday because the net connection was down at Lex and Flori’s place. Here’s the make up post.



Zed Shaw
is (in)famous within online dev circles for two things: his rant on Rails (which didn’t even spare Dave Thomas :D ) and his talk at CUSEC about how the corporate world screws with developers. He has retracted the former so here’s the latter instead:


Zed Shaw – The ACL is Dead from CUSEC on Vimeo.

It’s funny, informative, and depressing. A definite “must watch” for every developer who works or plans to work in the corporate world.

The Parable of the Two Programmers

The Parable of the Two Programmers is my first post in one of my other blogs. Even though it was written almost 25 years ago, this “parable” is still applicable to the software industry today.

Once upon a time, unbeknownst to each other, the “Automated Accounting Applications Association” and the “Consolidated Computerized Capital Corporation” decided that they needed the identical program to perform a certain service.

Automated hired a programmer-analyst, Alan, to solve their problem.

Meanwhile, Consolidated decided to ask a newly hired entry-level programmer, Charles, to tackle the job, to see if he was as good as he pretended.

 

The Parable of the Two Programmers is my first post in one of my other blogs. Even though it was written almost 25 years ago, this “parable” is still applicable to the software industry today.

Unlike normal parables, however, this one covers more than one issue in the industry. These issues will give me enough writing material for about 5 or more posts in the future, thus allowing me to procrastinate on writing for today. :D

In the meantime, just read the story. Try not to get too depressed about the ending, though. :P