Tools are(n’t) the Problem
I can definitely agree with the sentiment of the tweet. In his post he references an article by Peter-Paul Koch claiming that tools “have become the problem” (emphasis in the original).
Marco goes on:
This resonates with my own experience with Stack Overflow over the past few years and with doing Internet research in general seeking to answer any basic web development problem.
I’d like to cite some examples of this, but I can’t recall any right now. Send them to me if you run across any.
This issue becomes particularly significant where cross-browser compatibility comes into play. With mobile browsers implementing features in all manner of different ways, cross-browser compatibility is worse now than when all we had to worry about was whether or not a site worked in IE6, Firefox, and maybe Opera. With mobile, even using frameworks is not a sure thing.
There are reasons why all these tools exist today: rather than each web-developer trying to solve a problem badly, we decided to write frameworks that solved the problem well for a targeted set of common browsers. This led to things like Prototype, MooTools, jQuery, the YUI framework.
Want to get the dimensions of a particular element in the DOM or the dimensions of the document? Sure you could just roll your own that will work 90% of the time until the next browser update decides to break it and you or the next programmer to pick up your project has to go spelunking into your code to see what’s wrong, or just use jQuery and when that fateful update comes you or the next programmer can just upgrade jQuery and chances are the problem will go away without wasting time debugging. Problem solved.
Except, things aren’t that simple. Every programmer has his or her idea about the Best™ way of solving a problem. This leads to an overabundance of tools that solve similar problems in subtly different ways. Each tool, having a different developer behind it, will have different level of quality and different frequency of updates, or it might just stop getting maintained completely. Each tool will have completely different conceptual models and APIs so they’ll be incompatible. Replacing tool X that performs function Foo with tool Y that also does Foo won’t be just a matter of dropping Y in place of X, but a laborious process of testing and debugging.
This is where the concept of programming to an interface, not an implementation brings a ray of hope in an otherwise hopeless situation. If everyone writing a tool to perform function Foo would just agree that we’ll all use the interface IFoo then replacing X with Y would be trivial. The problem is, no one can even agree on what IFoo should look like.