Brian On Software

I took some time this morning to read two simple, funny and excellent articles, which I’d highly recommend if you have a couple of minutes to spear. Both articles are written by different authors, but they both converge to the same principles and ideas which I believe in my heart should never be forgotten: “By all means, if possible, keep it simple please!”.

The first article I’m writing about is “The Master, The Expert, The Programmer”, an essay written by Zed Shaw. I can easily relate with his article and ideas, because it deals with martial arts, coding techniques and simplicity. The idea behind martial arts (or any kind of art, such as painting, ballet or preaching) is that practitioner can normally fall in one of these three levels of expertise: novice, expert or master. Everybody starts out as a novice in everything in life (I’ve yet to meet a human being quoting the Declaration of Independence, just five minutes after leaving his mother’s womb). As you gain experience, wisdom and self-realization, your art begins to be a basic part in your life, such as blinking or breathing. You are now an expert on that field…or so you would think. I say “…or so you would think”, because just analyzing your own merits doesn’t specifically set you apart from one level of expertise to another. I think you become an expert in an area when you can actually speak, teach or share your knowledge with someone in a very simplistic way. If your message isn’t understood in, let’s say, ten minutes (I’m being generous here…), then probably yourself don’t understand your own message.

Getting back to the first article, Zed’s message in regards to code is simple: “Keep it simple!”. I have nothing wrong against XML, SOAP, UML, SOA and other buzzword-driven technologies (even driven is a buzzword now!). I know they’re not perfect tools or technologies, and I sometimes regard them as “functional patches”, but I think they’re a great foundation for future improvements, practices and tools. What I do have a beef with is when they are used in a way that, sadly, adds more complexity than necessary to solve a problem. Take for example this basic math problem. Suppose, I want an equation (a software would represent the equation in this example) that gives me a result of 4 (here the result is the problem I’m trying to solve). You can say that 2 + 2 = 4 and get your paycheck for it. You can also say 4 + 0 = 4, but sometimes people don’t like zeros. “It’s not sexy!” they would say. “Might as well use something better, something sexier”. So we go for an extreme solution that is soooo complex that we actually think it’s bulletproof! Cool…let’s go for log(85)*100-(50*3)-38.94189 = 4. This time you get a paycheck from the customer, and the guy in charge in maintaining your solution gets a headache. I don’t want to be that guy.

Sometimes I wonder why humans like to complexify things. Is it to represent someone’s signature, like graffiti on a wall? Our planet is simple (since it’s my blog, I’ll just say because I believe that God is simple). Nature is simple. For example, cats can’t swim; therefore you hardly ever see a cat near a beach. Programming and software development is already complex, since you’re dealing with two very difficult things: 1) Mathematical abstractions and 2) Humans. I’ll save my ideas on these thoughts for another post, but I just want to say this: Why add a third, or a fourth, or a fifth degree of complexity in our solution? God bless the Three Amigos and the Gang of Four, but do you really need to add graffiti in your solution? Don’t get me wrong though. There are some situations that are perfect for a pattern implementation or an UML diagram. But if you don’t need them in your problem domain, why use them? Keep it simple so that in the future, not only will you be able to tackle its maintainability, but there might actually be a tool or technology to ease your solution in such a way that all you’ll have to do is swap in and out your old solution for a new and better one.

The second article I read is “The S stands for Simple” by Pete Lacey. I almost fell off my chair laughing while reading his article. It’s short, hilarious, yet very realistic. He basically writes a dialog between a developer and a SOAP Guy. The SOAP guy can actually be anyone who swears by all these new technologies that are appearing on the Web. Like I said, I like to call them “Functional Patches”. It’s like in America, they say “Guilty until proven innocent”. I say the same thing in Canada regarding software development “Useless, until proven useful”. Check out this dialog….

Dev: Let me sum up. The definition of SOAP is in constant flux, SOAP is anything but simple, and it is no longer meant for accessing objects-even though that’s what all the tools still do.

SG: That’s about right, but we’re way ahead of you on this. We’ve deprecated the meaning of the SOAP acronym.

Dev: Really! What does it stand for now?

SG: Nothing.

Dev: (blink)

SG: Let me tell you about UDDI.

“Let me tell you about UDDI” This is the part where I almost fell down my chair.