Tool Specialization

I was in one of those big do-it-yourself-home-improvement stores with my father-in-law. He was looking for a cheap planer, and I was along for the ride (actually, I was looking at BBQ grills, but I'll save that for another story). Before us stood several planers and to the side was a jointer. I asked him what the difference was, and another customer standing nearby jumped in and explained. It had something to do with whether you wanted to affect the width of the board, or straighten the surface, or something like that (here's a link to an explanation: http://www.woodworking.com/ww101et-jointvsplaner.cfm). It seemed to me, from a complete novice at those things (well, not even that, to be honest), that they served similar purposes, but that for specific types of work or projects, you'd use one or the other.

That's kind of like buying a straight-edge screw driver because it's more versitile (you can use it for opening paint cans, which you can't really do with a Philips). The Philips is the better screw driver, because it's easier to screw with, but it's not as versitile as a flathead for some things. It's a question of specialization.

Some carpenters/handymen get excited about every new tool that gets invented because it makes some part of their job easier (in some cases, *much* easier). That's a good thing. However, for the complete novice like me, it's confusing and daunting to approach a
problem, especially if I'm asking for help. Invariably, I'll get multiple answers based upon which tools the particular expert is used to using. Some of the experts (or, in reality, just someone more experienced than I am) may not be keeping up on the new tools; others just have a preference for one tool over another. It's hard enough just choosing the right type of screw for the job!

Fortunately, in many cases, it doesn't matter. One tool or another will do the job. One type of nail or screw will do just as well as another...at least for the kinds of projects that I'm able to do.
Sometimes, I have to pluck down some money for a new tool, and that can be exciting (except for the plucking down part).

The metaphor of tools and programming is a great one. It actually works at many levels (not all, though). In this case, it's a question of specialization of tools. The more specialized tool tends to be useful in very specific situations, improves quality and efficiency considerably, but also tends to cost (especially if it's a powertool). It's an interesting metaphor: there's the initial cost to buy (and re-buy if it's easily consumed), the cost to maintain (keep clean, etc.), the efficiency gained, etc. For a particular "tool" in the development world, typically a new API, framework, design pattern, idiom, or whatever, there's the initial learning curve (the cost to buy), the cost of using it (efficiency savings), the cost to maintain it (what effect does it have on the maintainability of your code), etc. In some cases, the cost is fairly low. In other cases, the cost is considerably higher...those planers (even the cheapest one) were too much for my father-in-law.

In the case of the planer, it means that another solution is used that may not produce the quality or efficiency desired (such as hand-sanding, using an existing tablesaw, using a manual planer, etc.). Usually, in the development world, it's a little different: the efficiency isn't gained, but it doesn't necessarily affect the ultimate quality (of course, that's easy to argue against: for example, an API that is separately maintained may be of higher quality than a single, custom-build API).

One thing not to forget is the ever-present inter-relationship of tools and materials. Choosing a particular tool has an effect on the material used, other tools being used, etc. This is an additional hidden cost (how many times have I bought one tool, only to need to buy another that was somehow dependent on it). The same goes for programming. The choice of one tool may affect what other tools are used. This can be a good thing, or it can be a horrible, project-ruining thing. You can't have one end of a stick without the other. This means there's a need to somehow forecast the effects of the choice of a tool. It's surprising, sometimes, to see the effects one tool has on a project. Just remember that there's always a cost.

Another aspect of tools, especially large power tools, is space. Usually, you have a limited amount of space to store and use those tools. "Space" has a different meaning in the programming world, as storage is cheap. However, the use of many, many tools on a project make maintenance much more difficult, even if those tools are easy to maintain individually. This is because of the complexity of managing and maintaining an understanding of how to use them. In the programming world, it's much easier to forget how to use a particular API or framework. In the tools world, once you learn, you don't tend to forget too quickly (of course, I'm making an assumption on that, since I don't have enough tools to worry about that, yet).

This "space" issue also becomes interesting when a team of people are working on the project. However, I'll leave the issues of "teamwork" for a later story.