Mother of All Mantras

Blaine has put out a call to stop using mantras, including some of the catch phrases near and dear to an agilist’s heart, such as YAGNI, for one. His point is that they too often stifle the creative process. Before an idea is fully explored, someone on the team can claim, “That’s not the simplest solution,” and all right-side brain activity ceases. Blaine’s solution is that we don’t use mantras, which I have translated into the Mother of All Mantras: Don’t Use Mantras (DUM).

He’s right. The trouble is we tend to distill an idea down to its simplest form so it can be neatly packaged and easily communicated but in doing so, we squeeze out most of the subtleties of the original thought. Hence, its meaning is ambiguous and open to interpretation. “Simple” doesn’t mean “simplistic,” yet the two words are often used interchangeably.

I find this same ambiguity in the way people toss around design patterns.  Design patterns were intended as a communication aid between software architects, but people being people, they often confuse the issue. Recently, I was asked if there was another name for the Visitor Pattern. The question struck me as very odd, as if someone were doing a crossword puzzle. Yes, the GoF book provides alternate names for some of their patterns but only for purposes of cross-reference, as if to say, “This pattern has multiple names, but let’s agree on one name and use it going forward so we more easily understand each other.”

We tend to apply our own experiences  and prejudices to the meaning of words and phrases. This works fine with art but it doesn’t work well with technology.

If I asked you explain the Factory pattern as defined by the GoF, you may go on and on about where it applies and how you’ve used it, but you would be wrong. I defy you to find the Factory pattern in the GoF book. There isn’t one. There are Abstract Factory and Factory Method.

In short, we can’t totally diregard the tools we use to communicate, but neither can we use them with total confidence. Don’t be afraid to use a mantra or a catch-phrase or rule-of-thumb but always be prepared to explain your idea another way.

The Why of Code

There’s been some discussion lately about literate programming and related ideas (syntactic sugar, et. al.) centered around a quote from Abelson & Sussman’s book, Structure and Interpretation of Computer Programs: “Programs must be written for people to read, and only incidentally for machines to execute.”

Nutrun thinks literate programming potentially masks inefficiencies and bugs. By way of example, he says, “The moment something like submit_the_payment_and_send_a_message_to_the_customer…somehow doesn’t send messages to the customer, while making a couple of redundant roundtrips to the database, we’re in trouble.” But that is true whether or not the code is literate.

I think it’s a disingenuous example. The issues here are error-handling and orthogonality rather than whether the method name is or isn’t literate. Literate programming doesn’t prohibit bad programming practices. It’s meant to convey a quick understanding of the code’s purpose. If customers were complaining they weren’t getting their messages, a literate method name clues me in faster than one named, say, “execute.”

It’s obvious that code must be written for both people and machines. The difference is that machines execute code while people interpret it. We need to understand why the code was written. Code doesn’t have to be perfect English but it has to be more than merely readable; it also has to be unambiguous. Literate programming aims to accomplish that goal.