Why the best tool for the job isn’t always the right tool for the job

09 Nov
November 9, 2012

We started our #hackaway with some lofty goals for hearquotes. I spent the day working with the team focused on developing the web application, and learned a lot in that 24 hours about javascript, web applications, my coworkers, and myself.

Early in the day, I made the decision to use Backbone to drive the web application. I knew that Ron, the other front end dev working with me, had some experience with Backbone, and I had been tinkering with it in a side project. There has been a really steep learning curve for me with backbone, and I still didn’t feel completely comfortable it, but felt like it was the best tool for the job. Plus, this was meant to be a day for learning, stepping out of my comfort zone, and working with a technology that I wasn’t necessarily familiar with, so I thought, “Let’s go for it.”

Knowing there were plenty of examples and tutorials out there for the list-and-detail-view-style web applications with Backbone, I felt confident that we could work our way through any roadblocks by referencing how some of the open-sourced applications or tutorials solved the problem.

The basic flow/structure of hearquotes dictated the homepage would display a list of quotes, with the top-rated recording for each one displayed inline. Each quote could have one or more audio recordings associated with it, so you could drill down into a ‘quote detail’ page that would display all the recording for a particular quote, and let you upload your own, or even comment and share on a particular recording for any given quote.

From my experience with Backbone, it seemed like the best tool for the job. We started right away by modelling the Quote object, and I started working on a Router to wire up my Views. Ron started working on the HTML and the templates for the views. Things were going slower than expected though, so around 1pm, I asked a few more people to jump in and help out. Shawn, Tim and Steve all stepped forward and asked how they could help.

Unfortunately, since Ron and I were the only ones with any real Backbone experience, the people we brought in to help out had to first wrap their heads around Backbone before they could start on any real work. The awesome part about this team is that rather than grumbling or getting discouraged by this, they all jumped in to Backbone right away. They asked great questions (a few of which I was able to answer), started tinkering, and before long I heard Shawn say, “I’m starting to get this… this is cool.”  Their enthusiasm was inspiring.

What I needed the most help with was pulling in the actual data from the web service that the backend team was building. The primary source of my knowledge with Backbone is through Parse’s Javascript API (which is just a fork of Backbone), so I knew that the RESTful  stuff was possible, but Parse’s framework hides all the nitty-gritty from me, so I hadn’t actually interacted with anything that resembled a URL.

Tim and Shawn jumped in to this issue and it became apparent within a few hours that there were going to be some big hurdles to overcome with the way Backbone deals with, and we constructed, our API. There was some confusion, and we couldn’t find a tutorial that offered any clarity for our particular situation.

We were faced with a decision around 5pm: we could either continue with Backbone, or switch over to just using jQuery ajax calls and inserting the data into the DOM. We didn’t feel it was the best way, but we all knew how to do it this way. It was agreed upon that we should switch gears and tackle the problem with jQuery.

It’s not easy to make a decision that results in the feeling that you’re starting over 8 hours in to a 24 hour hackathon, but in the end, we were able to present a working product to the company.

Of course, we couldn’t leave it alone, and Tim and I were exchanging emails throughout the weekend, continuing to work on the Backbone implementation on our own time. By the end of the weekend, we did actually get things working with Backbone, but it was unlikely we could have figured it out in the time allotted by the hackathon, with the increasing mental haze that thickened as dawn approached.

I learned an important lesson about choosing the right tool for the job, as opposed to the best tool for the job. For the hackathon, the right tool was jQuery loops that inserted ajax data into the DOM. The whole team is familiar with jQuery, it’s simple and straightforward to use. Even if it’s ugly, and less than ideal for the long-term solution, the short term considerations should have pulled more weight in my initial decision.

In summary:

  • The best tool for this job was Backbone (correct me in the comments if you think otherwise!), with a much more maintainable application data and templating structure.
  • The right tool for this job was jQuery, because we could involve more people in a short amount of time, and get something up and running by the end of the hackaway day.


Without an intimate knowledge of Backbone, it was silly to try use it to build hearquotes in a day. When time is your biggest constraint, and the goal is to get something working, it’s better to use a tool that you understand, even if it isn’t the best tool for the job. If we built the app with Backbone, it may have had a more solid foundation to build off of, but at the end of the day, we probably wouldn’t have anything working to show the rest of the company.

Will Dages

Will is the Manager of Web Development at Findaway World.

More Posts - Twitter - Google Plus

Tags: , , , , ,
© Copyright 2017 Findaway. All rights reserved.