Tag: Neal Ford

Polyglot Programming

no single language

In this day and age, knowing one programming language is not enough to develop software.

Take for example web development. You need to know at least 3 different languages to write a web application:

  1. HTML to provide a user interface.
  2. A web scripting language (e.g. PHP) and possibly a general programming language (e.g. JSP + Java, ASP.NET + C#) in order to process the data entered by the user.
  3. SQL so that you could save the data to a database.

Of course, these are just the bare bones of a web application. More practical web apps require the developer to know more technologies:

  1. CSS to make the interface more appealing and manageable.
  2. Javascript to make that interface more dynamic (a must in Web 2.0).
  3. Another markup language like XML and JSON to facilitate data exchange (e.g. for AJAX)
  4. A web framework to reduce the complexity of a large system.
  5. A scripting language to automate the build and testing of the system

Developing for corporate clients require even more technologies:

  1. Ways of interacting with services on other servers which, when listed down, looks like alphabet soup: SOAP, RPC, CORBA, SOA, etc.
  2. Various security protocols, with keys, certificates, and whatnot.

Continue reading “Polyglot Programming”

Angry Monkeys

Go near that stepladder again. GO NEAR THAT STEPLADDER AGAIN. I dare you, I double dare you, motherfucker. Go near that stepladder one more goddamn time.

As a follow up to Cargo Cult Thinking and Best Practices, I’d like to share a story used by Dave Thomas (one of the authors of The Pragmatic Programmer) in a keynote Angry Monkeys and Cargo Cults.

I first heard this story from Neal Ford’s presentation on ways to improve your code. Fortunately, the presentation is a short run down of his book The Productive Programmer and this allows me to copy-pastequote the book instead of having to narrate it using my own words.

Back in the 1960s (when scientists were allowed to do all kinds of crazy things), behavioral scientists conducted an experiment where they placed five monkeys in a room with a stepladder and a bunch of bananas hanging from the ceiling. The monkeys quickly figured out that they could climb the ladder and eat the bananas, but every time the monkeys got near the stepladder, the scientists would douse the entire room in ice cold water. You can guess what that generated: angry monkeys. Soon, none of the monkeys would go near the ladder.

Then the scientists replaced one of the monkeys with a new monkey, who had not been subjected to the blasts of water. The first thing he did was make a beeline for the ladder, and all the other monkeys beat him up. He didn’t know why they were beating him up, but he quickly learned: don’t go near the ladder. Gradually, the scientists replaced the original monkeys until they had a group of monkeys who had never been doused with cold water, yet they would attack any monkey that approached the ladder.

The point? In software, lots of practices on projects exist because “that’s the way we’ve always done it.” In other words, because of angry monkeys.