A Phrase Past Its Expiration Date

I've been a fan of Roger von Oech for a long time. I love his books, blogs, and cards (yes, cards). His latest blog entry entitled, "A Phrase Past Its Expiration Date", struck a chord with me that I thought I would share. In it, he asks his readers what phrases are overused and should be put to rest. His phrase was "It is what it is." The reason why was because it is commonly used to end debate and thought.

There are several phrases that carry the same role. Here's mine:

• "YAGNI" also known as "You Ain't Gonna Need It"
  If I never heard this phrase again in my entire life, it would be too soon. I hate it. The original intention was well meant, but many a poor developer took it the wrong way. I've heard it uttered too many times to end discussion because a weak mind couldn't support their assertion.


• "Do The Simplest Possible Thing That Could Work"
  Another well-intentioned phrase that originally came from Albert Einstein. How could it be bad? Again, I've heard it from one too many hacks to be lazy and not think through their design. It was once used in a debate to store records in XML files instead of a relational database. Even though it was known that the system was to deal with lots of records that had to be randomly accessed. Why? Because they thought relation databases were "hard". The resulting XML files architecture turned out to be way more complex than any OO mapping tool could dream of being. On the surface, the XML seemed simpler, but only when you ignored all the other factors to take into account. The above phrase ended the debate despite cries of the obvious. Confusion abounds because simple is often confused with easy instead of elegant.


• "If It Ain't Broke, Don't Fix It"
  The maddening catch all to stop refactoring code that everyone fears. This one has been used because apparently certain developers like hearing the buzzing of pagers at 3am. The code in their eyes "worked" even though it was riddled with bugs. The code need to be cleaned, but they just wouldn't let it go. Fear is a terrible thing to use matras to justify.

That's my list for now. I'm sure there's more. I'm really bothered by most mantras because they are used in the most inappropriate places. I'm for debate and rational thought. Anything that short-circuits that annoys me without measure.

"Considered Harmful" Considered Harmful

It's official. "Considered harmful" can be added to list of cliches to avoid. It needs to go into retirement along with factorial and prime examples.

My Job Went To India

Sam comments on "My Job Went To India" by Chad Fowler and I think I have been too harsh with this book. I have refused to buy it from the title and especially the cover. Sam discussed the problem they had with that. When I came out of college, there was a ton of "scare" books about how all programming jobs were going overseas. Let's just say that was several years ago. I hate "scare" books and the title of Chad's book smelled of that. I refused to even open it in the store. Sam explains they wanted a funny title and it didn't sell because of that. I can understand that completely. I've heard nothing but good things about the book and maybe it's time for me to my bias aside and to read it. But, I will probably put a book cover over it because I can not stand the title or cover. Let's hope the pragmatic programmers re-title it and re-release a second edition with something less scary or funny.

Besides, if it was a joke, it wasn't funny. Scare books are cheap shots and not worthy of anyone's money. So, if they are wondering why sales were poor, I gave my reason. I trust Sam and I will probably buy it now. What a marketing mistake though.

T.H.O.

T.H.O. used to be an acronym that a friend of mine would use to describe code in which it was apparent that a developer put his ego before the good of the team. The code exhibits clever behavior when a simple approach would have sufficed. But, the developer had to show off that they knew a certain trick. Sometimes, it can be more sinister. A complete library written from scratch when there are open source equivalents better tested and designed. But, they just couldn't resist doing it themselves (also known as the "not invented here" syndrome). They think they can do better. But, normally, it is some poor maintainer that has to deal with their "better" solution after they are long gone to the next T.H.O. In this day and age, I can't see how anyone can justify writing a library from scratch if there is an open source equivalent. It boggles my mind. Of course, if you think you can do better, then do so on your own open source project and live with the code before causing a maintenance nightmare for years to come. Besides, you'll get valuable feedback and fix bugs from other developers. Value simplicity and doing the least to get the most.

"Get 'Er Done" Programming

OK, if you don't like my rants, stop reading now. I've been trying to write this entry for a while without sounding venomous, but I just can't do it. But, I'll start with what I call "Get 'Er Done" programming. Now, I'm sure you've seen the highly annoying "cable guy" comedian that utters this despicable phrase. But, it's what I hear when I see lazy code written until it works. It's maddening I tell you! Basically, writing code until you can get a simple example to work and stopping there is lazy. Failure to look at the big picture should be punishable. But, I see examples of it littered everywhere.

Alright, you might ask what does "look at the big picture" mean exactly? What I mean is do proper analysis. Think about your problem before you write any code. I'm not advocating huge up-front design here, just thinking before you burn up your keyboard. It might also entail asking a few questions about the problem to fellow team mates and the user. It all depends on what your coding and your understanding. Looking at the big picture also means in making your code to be able to have future extensions that you can't anticipate. You might think this is impossible, but it's not. If you make the objects small, each one has a single responsibility, have good intention revealing names, and make small methods, then you have made your code extensible.

The whole point of this blog post is don't be lazy and make life difficult for the person that has to come behind you. Think about what you're doing and make your code easy to read. Remember there is always someone coming behind you that has to learn what you did. Make it obvious and show that you cared by going beyond the simple example. Well, looking back this wasn't so bad was it? Sometimes rewriting and thinking about what you write works too.

I'll end with a piece of advice: always re-read your code once you have written it and it works. You would be amazed at what you catch (misspelled words, uncalled methods, unused variables, etc). Of course, with today's tool this is quite easy. In fact, Eclipse can flag most of these with a warning, but it's still a good habit to read your code before you check-in. Let's stop "Get 'Er Done" coding today. Besides, only idiots write code that way and I know you are not an idiot, right?

Jargon

I just have to scream, "RIGHT ON!", on this post from Penelope Trunk: What the jargon you use reveals about you. I think this is true for us technologists as well. See my post below about Idea Killers. Stop using jargon and mantras! Think! Wait a minute? Isn't that a mantra?

I Can't Stand Pretentiousness

There I said it. I don't care what it is. A programming language, methodology, religion, music, art, coffee, movies, or what have you it doesn't matter. It reeks to me and I'm sorry for anyone who uses it to make themselves feel superior. Somethings I don't understand being pretentious over like wine (angry grapes because they are bitter for being made into that) or scotch (yes, I would like some turpentine please). I've tried them, I didn't like them. But, if you do, then more to you. It's not a reason to think your are better. But, I digress. I'm always running into people that stick their noses up based on what I like. Nothing cuts off a conversation sooner for me than when someone says, "Why do you listen to that Y garbage?" or "How can you stand to program in language X?" I just walk away because you are not worth my breath. I think it blinds your thoughts and makes it impossible to reason. I would rather hear, "Why do you like X?" or "Give me the top greatest pleasures of Y". I like to ask those questions. I'm always amazed at the answers.

I guess it's my southern upbringing. I like simple things, but I also enjoy richer experiences as well. I just hate it when someone is not open to the joys of the simpler things. I listen to all kinds of music, food, or what have you. I will try anything once. And I research any language I can get my hands on. They each have their strengths and pluses.

Now, don't mistake pretentiousness with excitement. I love excitement and a healthy jubilation for your newest discovery. But, when it turns to thumbing your nose at something, then I think the coin has been flipped.

Oh well, I had to get that rant off my chest. I'll probably read it tomorrow and go "What the hell were you thinking?!" Or maybe I was just trying to say, "There's something positive about everything, find it", in a really negative way.