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.

Bike Hooks

I think one of the banes of existence for suburbian families is the existence of bikes. The mobility of them is good for your children, but the storage of them tends to be a pain. With several bikes to store and limited storage space, I faced a dilemma. On the one hand, I want to encourage my kids to use their expensive bikes. On the other hand, I want them out of the way (okay, out of my way).

So, there I was, putting up a 2x4 in my garage, attaching it horizontally over my head (though I used a step ladder), with bike hooks appropriately screwed in so that I could hang the bikes out of my way. Of course, my kids couldn't get them down themselves, but they were out of the way (so you can see how my priorities were set right from the start). Being a novice (if that) handyman, I figured it was a fairly simple task: attach a 2x4 to a wall (since I didn't want to attach the hooks directly to the wall, for various reasons) with the hooks attached to the 2x4. Pretty simple, even for me (this is like asking someone who doesn't know how to cook to boil water, I thought).

Now, the question of what I would use to attach the 2x4 did come up, but was quickly resolved, since I'm a screw kind of guy (as opposed to a nail or glue kind). It's a pre-disposition, I guess, but I didn't think it that big of a deal, since I felt that the screw would hold the wood better, hence giving me an overall better solution. Did I mention that I was a novice at this? So, I bought a bunch of large screws (well, there's the 1 1/2 of 2x4, about a half inch of drywall, and then some extra to actually hold it in place inside the backing stud, so you can imagine how big these screws were), got on the step ladder, held up the 2x4, and started the first screw (okay, I also used a cheap stud-finder and made the appropriate marks).

For those that are more experienced with this sort of thing, you've probably already figured out what I did wrong. For those that aren't, here's the clue: I stripped every single screwI put in (assuming that I was able to get it in, since I wasn't able to, in many cases). After a lot of cursing, yelling, and other childish things, I finally stepped back, grabbed a bike, and threw it up there (fortunately, it actually held).

I remember telling this story to someone about my frustration with this simple project. They kindly pointed out that I should have pre-drilled the holes before starting the screws. Oh. Right. Of course. I knew that. I was a little embarrassed.

There's an inter-relationship between tools and the materials they work on. Knowing your tools isn't enough. You have to understand how they interact with different materials, how those materials interact with each other, and how to work around the inherent weaknesses in the tools, the materials, and your ability to use them. Screws are an acceptable method of hanging 2x4s; a nice power drill is acceptable to screw them in; assuming the screws were embedded within the studs, the bikes could hang for many years. But, pre-drilling the holes in the 2x4 helps the interaction between two materials: screws and wood.

How often, in programming, do we discover a new "tool," an API, framework, method, idiom, or whatever that appears to make our lives a little easier? It's great. We want to try it out. How many projects were hurt because we didn't understand the relationship between that new tool and our existing ones? Did they interact well? What effect does it have on maintenance? If the files containing our code, our configuration, and our data are considered "the material," and the idioms, APIs, frameworks, etc. are our tools, how well do we know how they interact and work together?

The simple use of a tool with a particular material is not enough. A screw, a 2x4, and a power drill don't automatically define failure. They can be used together for an easy success (or an embarrassing failure). I think it's important to stop and analyze what it is we're doing before thinking that there's a simple answer and jump right in. Sometimes, we may find ourselves skipping the obvious, thinking the answer too quick and easy.

I ended up tearing down those bike hooks. I put up shelves, instead. Now the bikes are more easily accessible to my kids, but are still in the way. Even a seemingly simple solution to a problem may still be a ladder up the wrong wall. But that's a lesson for another day.

Let's Get Started

Programming tends to be a very abstract, open-ended activity. A very specialized language is used to communicate with a machine that understands a very limited, but powerful, mathematical model (i.e. ones and zeros). These machines have their own language, one that does not translate well into verbal or human terms. This communication, then, is a layer of abstraction: Verbal/Written language (i.e. English) -> programming language (i.e. C/C++, Java, etc.) -> machine code (i.e. x86, SPARC, etc.) -> ones and zeros (i.e. um...1, 0).

Because the number of layers or abstractions, especially between the verbal/written language and a programming language, causes some form of cognitive dissonance (an interesting subject unto itself; Wikipedia has a good definition; but here, it basically means the difficulty in translating English, for example, to Java, C, or any other programming language). Hence, the need for perceiving our particular paradigm, coming to grips with it, and adjusting it are not only necessary, but are paramount to doing more than just twiddling our fingers on a keyboard, popping out cute little programs that do little beyond excite our creative needs.

I think it becomes interesting, though, to step back and relate those perspectives and paradigms we have on other areas of our lives and analyze them, looking for appropriate metaphors, analogies, and whatnot. I think this lessens the cognitive dissonance because we familiarize the layers of abstraction with realities that we're used to. The common metaphor of programming technologies and techniques with tools is a great example of this (and one that I will explore at greater length in the future).

So, here I've started a blog with the desire to lessen the natural dissonance in computer programming and to explore other experiences and to relate them to writing code. My hope is to gain insights into the process of development, the process of building, and creative work. I fundamentally feel that computer programming is one of the most fascinating fields for this simple reason: it is able to combine creativity with science with engineering with craftsmanship.