Rage: Do not recreate what is right under your nose

So I thought it would be great to express some of the things that I constantly complain about to my co-workers and friends. I usually keep my "Rages" private, but it is time to let the world have a piece. Since I rage quiet a bit, I figure I will hold myself to a monthly outlet.

A Rage will consist of three main parts: Beef, Fuel and Resolution. Beef is the topic of the rage, Fuel is what sparks the Beef into a Rage and Resolution is what YOU can do to extinguish my Rage. I hope you all find it amusing and/or want to Rage back.

Beef:
This Beef goes by many names. Recreating the wheel, duplicating code and the DRY (Don't Repeat Yourself) principal to name a few. I see these mistakes all the time and I'm not going to lie, I've been guilty myself. Being able to use existing, tested and released functionality is always going to save you and others (QA) time in the long run. It also enables you to focus on your major task and in effect, get more done. This in turn makes you look good and will eventually turn you into "The Man".

Do not take it from me, there is tons of literature and facts out there that march to this same tune. One of my personal favorite books, "Pragmatic Programmer", talks a bit about this, among other things. If you have not gotten a chance to read this, please add it to your toilet reading regimen (or your normal reading time).

Now Raging is not something that just happens, there are certain events that fuel this rage.

Fuel:
Okay, so I'm going to explain the situation in a way that protects anyone involved, because I want the focus on the problem not the person. About a year ago I was noticing that a lot of code was being duplicated around the code base that basically caused game states to time out. So being the proactive developer that I am, I added a class called "TimeOutState" to the state machine library. Instead of just extending the regular old state, you could now derive from the TimeOutState and gain functionality to customize your time out behavior. Obviously there are much more elegant ways to do this, but I was working with what was there.

So I'm thinking, "Sweet! Now people will check out the changes to the library and the next time they make a state they will make use of this option." Much too often I'd discover the opposite. I still come across currently being developed code, recreating this functionality.

No big deal, right? WRONG! More code can and will always equal more bugs. I can not count how many times we got tickets in trac that said something like, "Bad thing happened when state times out". When you add up the time for QA and Software dealing with these kinds of trivial issues it can add up to real $$$. Don't think the higher ups (technical higher ups of course) are too stupid to notice, their job is to save the company money. The more tickets that pop up that are similar, the more they will notice a problem.

Resolution:
This is really simple. Don't use external libs without looking at their feature sets! Don't start writing something without first checking the code base for similar functionality! You may think that just doing it yourself will be faster then looking it up. This could very well be correct. The problem comes when you need this functionality again. You will need to try to find your previous code to copy/paste, or write it again. Not only will doing that introduce potential bugs, but it will also add to the ever growing code base that needs to be maintained.

If you are keeping up to date with the libraries you use, you will come across other useful functionality that you can store in your memory bank (your brain) for future reference. Knowing the libraries that you use will make you more useful/efficient and as I mentioned earlier, get you one step closer to being "The Man".

You do want to be "The Man", don't you?