Choosing Your Tools and Solving Problems

In any project there comes a point in time when you think to yourself, “This has probably already been done before.” If you don’t get that then maybe I’m just weird, but I prefer to not have to reinvent the wheel. There are plenty of intelligent people out there who must have had this problem before, and if not…then why is mine different?

The Wheel?!? Oh my.

So you’ve decided that you need to use someones library. You’ve been searching and found many around. Great. That means you don’t have to spend the time to develop the solution yourself. In this case, you’ll want to pick the right tool for the job. But, how do you distinguish which is better? You may be thiking, easy, just pick and go. But, if you’re building a product, this decision can be crucial. It can affect many peoples time. So, again, how do you pick the right tool. While each situation has different dependencies, here are some of the things I use to decide.

What is the barrier of entry? In many cases I’m not going to be the last person to touch a piece of code. And, on top of that, the next person to touch it will be in maintenance/bug fix mode. So, I want something that is easy for someone else to jump into. This mostly means API. While there are a few other pieces to this that I’ll explain later, API is what you will use inside your code. Thus, someone coming into your code should be able to make sense of it without having to ask you all the time. So, the library should be easy to learn.

What is the community like? This is a very big factor in the decision because, like above, if the code is not easy to understand or if I suspect that there are issues with the library, I have the ability to find out when the community is large. This doesn’t mean that small communities are not helpful, look at the Axiom Stack…Small for now, but staying active on the forums. Is there some excitement? Is anyone talking about the library/tool?

Are you trying to sandblast a cracker? Every engineer goes through the phase where s/he architects for the moon. This is a bad thing. Using Dojo or ExtJS to alert some information to a webpage is sandblasting a cracker. Getting a backhoe to pick up dogcrap is sandblasting a cracker. Building a $4000 machine to play Pong is sandblasting a cracker. The point is, don’t overdo it. Pick something that is going to work for your problem, but that wont hinder performance, decrease everyone’s productivity, and cost a lot in the long run. You want the gains to be greater than the cost.

What is the quality of literature available? One thing I’ve noticed on the Django site is that the documentation is phenomenal. Not only do they have a 20+ chapter book detailing A-Z on Django, but they have their API documentation as well. While the API docs could use some sprucing, the information available is incredible. This is the same for ExtJS. The documentation is very thought out and appears as though it was a focal point in the development process. To add onto this, are there any hard-copy books available. Java has numerous books available. This makes it easier to find quick answers or to learn something from the “experts”.

What are we, neanderthals?

This is the time when you’ve searched. You find nothing. Not a single result on Google. You check to make sure you didn’t fat finger the search query, and still nothing. Well, it’s time to break out the red bull and prepare for that all night-er right?

Stop! It’s hammer time. First, before you start writing any code, rethink your problem. A lot of times you’ll create problems that don’t exist. By this I mean, you’re attempting to solve an issue that isn’t there. Another common situation is that you forget about the overall picture because you’ve been staring at the same problem for 15 hours straight. Take a break and come back to it. It may be that the problem you thought you had is a bit different or that there is a slightly different way of thinking about it. By removing yourself you allow your subconscious to process it a bit before returning.

Use your brick wall. In almost every programmers toolkit exists a brick wall. This is not for slamming his/her head against it. Instead it’s a person that s/he trusts to bounce ideas off of. Quite a lot of things make sense in my head…it’s unfortunate that those things don’t always pan out in reality. Thus, the brick wall. If I can bounce my ideas around a bit I’ll come to a better solution. Even if the person I’m talking to doesn’t say a word about what I’m talking about.

Buckle up. If you’re confident that you’re problem exists then it’s time to hit it head on. In the words of Rands, start! If you wait around trying to contemplate the issue, you’re just wasting time. You’re confident that you have an issue without a solution, so dive in and start hacking away. Use some common sense when you are solving this problem. If you suspect that the problem may need to be solved again then start making your own library so that others can use it.

I always find that taking a second to think about my problem and then bouncing it off the brick wall helps whether there are tools or not. But, I really find that the community can make or break my use of a library. The collective minds of others is a great thing to have.