Friday, August 19, 2005

Shhhhh. I'm Hiding

So here I am, sitting, scrunched up under a large desk (it has to be to fit my large bulk). Why am I here? Picking up a dropped pencil? Playing with my computer's various cables? Cleaning up all the dust bunnies? No. I'm hiding. Not from my boss, but from my kids. We're playing hide-n-seek.

Am I having fun trying to see how well hidden I can be? Not particularly. In fact, playing with my kids can be downright boring sometimes (of course, at other times, it's a lot of fun, so I'm not complaining about the "raising kids" thing). Ever been bored doing some work for a client? Are some programming tasks downright boring? Absolutely.

But, we do them, anyway. Why? Because, down the road, it'll make for a better product, happier client, well-adjusted kids, and a happy marriage. We do lots of things in any given day that we don't enjoy (raise your hand if you enjoy your commute!). Most of the time, we do these things for some payoff down the road (in some form or another). So, ultimately, that's a good thing, right?

Darn, they caught me. Now it's my turn to find them. I wonder how long that will take...

Tuesday, August 09, 2005

The Movers, They Come

I moved. That is, I physically moved myself and family from one house to another. If there's one thing I learned from that experience, it's this: don't move unless you have to. It's a pain.

In fact, I think I've heard of executives saying the same thing about building software. Hmm....

Since I'm not as young as I used to be, I decided not to move myself. This was definitely an outsourcing job, so I hired movers. The process I went through to choose who to be the lucky company was fairly obscure: I made my wife do it. And upon what criteria did she use? If she could understand them, they got the job. Actually, when you put your house up for sale, you get all sorts of advertisements from moving companies. Some of them even call you on the phone.

So, we got lots of advertisements, a few phone calls, and a lot of headache in trying to figure out who to choose. Obviously, there's the price. There was a fairly large range of hourly rates, fixed prices, etc. We had a pretty good idea of how much it *should* cost, but certainly not an exact figure. Ultimately, it came down to what I said: one of them left a message on our answering machine, and we could understand what they were saying. And they weren't too expensive.

So, my wife called them up, hired them, and we got moved. Did we make the right choice? No, unfortunately not. Was it a nightmare? Yeah, but it would have been no matter what (boxing and unboxing isn't what I call a dream come true). Should it have been better? Sure. Could it have been with a different mover? Certainly (though it could have been worse, too).

Moving is moving...you put boxes on a truck, you tape up furniture with blankets, etc. and you load/unload. It would seem to be a commodity. To a certainly extent, it is, since there are *lots* of moving companies (and many of them compete on price). However, there's a big difference between a smooth move and a nightmare (okay, mine wasn't really a nightmare...it was somewhere in between). But, as a consumer, how do you tell the difference?

There are a lot of consulting companies out there (I'm sure there are many who consider it a commodity service, since many compete on price). How do you tell the difference? When executives, managers, or whoever have to choose, how do they go about it? There are some obvious pieces to that puzzle, such as the cost (that includes dollars, but also includes other kinds of costs), and knowing what's available (it's hard to get picked when they don't know you exist). But, ultimately, what differentiates them from each other?

I've no idea. Sure, with the movers, I could have asked for references. I could have done some additional research, background investigations, asked friends, etc. Would that have made a difference? Maybe. It would certainly have helped. Would it have necessarily given the best answer? No. The moving company I hired claimed to be a different kind of moving company. How? I certainly didn't see the difference (not that I move frequently and can compare).

As individuals, we stand up and shout about how different we are. We're unique! My company is unique and different! (Does that mean it's "better?") Your company is unique and different! How and why? Is it the kind of different that I'm looking for?

Fundamentally, I don't have an answer. How *do* you tell the difference (and if I could, does it matter to me)? It's tough being a business.

Monday, June 06, 2005

On and On

My wife and I decided to redo the floor, replacing the carpet with laminate. Since that job is well beyond my capabilities, I hired someone else to do it. It's been an interesting process.

First, it's taken a lot longer than I expected, though I guess I should have known better. However, the interesting aspect of that is that the parts of it that I would have expected to take a long time didn't, and some of the parts I thought wouldn't, did.

One of the rooms that's being redone is our family room. It's a fairly good-sized room (much bigger than the other rooms). I figured that that would take a while. It didn't. In fact, from a square-footage perspective, it took a lot less time than many of the other rooms.

As I watched the work being done, I realized why. My family room is basically square, so the work progressed quite quickly there. The stuff that took a while was the doorways, some of the transitions (where one floor type meets another), and some of the repairs (fixing a particular piece of laminate out in the middle of a floor is a pain).

Though the job of laminating the floor involves some fairly standard tools, directions, and the like, there turned out to be a number of gotchas that would have caused me pretty big headaches. It was in these situations that I express gratitude that it was not me who was doing to work. I guess that's why they pay the professional the big bucks.

I saw a lot of obvious corollaries to the programming work that I do. I can see the big difference a more experienced professional would have over someone like me. It's common for projects to take longer than expected. Fortunately, we'd agreed on a price before the work began, so the fact that there were little "gotchas" didn't cost me anything (which means that I'm a little surprised that anyone would want to hire a bunch of programmers for time and materials...).

To the inexperienced eye, the work seems both simple and amazing. Could I have done the work and saved myself a lot of money? Of course. Would I have done as good a job? Of course not. Was it worth it to have someone else do it? Sure, because I put a price on how valuable I perceived the work (the finished job, actually). There were many aspects to the decision, such as the criticality of a successful job, the expected cost, the ROI (in terms of value added to my house), disruption to life, etc. Ultimately, it came down to the criticality of a successful job. If I were to do it, there's a bigger chance of failure (failure in terms of the quality of the job). Since this is my floor that I walk on every day, any "bugs" would be rather easily seen (I don't want to buy *that* many rugs).

One aspect of it is the fact that the manufacturer of the laminate flooring goes out of their way to make it easy to do. They build helpful tools; they build the product such that it can be pieced together easily; I even expect they've got easy how-to guides. All in the name of selling more products. So, they *expect* me to do it myself (they sell more that way). However, I *still* hired a professional.

They're making tools for programmers easier and easier. I expect that many non-programmers wonder what all the fuss is about. They probably look at the projects in a similar way: both a wonder at the simplicity and amazement at the complexities. Those complexities come up when the tools don't quite measure up and you get hit by some "gotcha" that you don't know how to deal with. That's why you hire the professional.

Wednesday, May 04, 2005

Concentration

We're doing some renovations that have caused the door to my office at home to be somewhere other than where it should be. On top of that, my office isn't completely put back together (it's pretty much scattered around the house until some more of the renovations get done). With no door, there's no barrier to the children running into the office and wreaking havoc (or, more specifically, bugging me while I'm on the computer).

As you can imagine, the task of concentrating under such conditions is nigh unto impossible (at least for me). Since I sit in a cube at work, I don't have a door there, either. Fortunately, I don't have any children at work, though I certainly have co-workers (who certainly aren't as bad as my kids).

As you can imagine, concentrating can sometimes be difficult, both at home and at work. At home, though, it's a more temporary thing, since the door that I normally have keeps things somewhat quiet.

It's surprising to me that employers don't go out of their way to convince their employees to work from home more (specifically, programmers). I'd expect that their productivity would be much better. In fact, for some positions that I've held in the past, I've been able to work from home on occasion. If my experience is typical, there's a considerable amount of productivity to be gained by working from home.

Most of the concerns about telecommuters are bogus and have more to do with a lack of management skills than with "cheating" workers. Trust goes a long way toward boosting morale, and telecommuting is one way to prove trust very easily.

Tuesday, April 26, 2005

Out Of Shape

I was out walking with my wife and kids the other day, and we decided to take the "long" route. That means we walked more than a couple of minutes. In fact, it took us half an hour. Though the weather was nice, and company was great, I was pretty worn out by the time I got back. I knew I was out of shape, but it was pretty embarrassing. Apparently, I need to "get out" more.

I've been in a number of "architectural" roles during my career, and in each of these, I've done a range of coding. In some cases, I did a lot; in others, I did very little to none. I remember those times where I moved from a position of doing very little coding to a lot, and I remember how rusty I felt. I was "out of shape" in my coding. Though nobody (fortunately) noticed, I felt embarrassed that I could forget so much. In fact, I've forgotten much that I learned early in my career (or in school), such as how to write Pascal.

It's an unfortunate (or fortunate, depending upon your perspective) part of life that we tend to forget things (okay, some people have better memories than others...I'm one of those that forgets pretty much everything), especially when we don't "remember" it often. In the technical world, that's the difference between hitting the ground running and falling flat on your face when the gate opens. You can always get back up, but it takes a little while (and it's a bit embarrassing, too).

Knowing that this happens makes me a little nervous about taking certain types of roles. If I take this job or that promotion, will I like it? And if not, will I be able to go back? Does the same kind of thing happen to a team on a collective level? If so, that could have a significant impact on productivity on a project.

Tuesday, April 19, 2005

Memories

My family was playing Charades For Kids the other day and my 4-year old did a charade of a computer. She knelt on the floor, folded her arms, and sat really quietly (she's not known to sit quietly). As I thought about how cute and funny it was, I'd wished that I'd taken a picture of it (or, even better, a video).

That got me thinking. Why do we take pictures, videos, write journals, etc. in our daily life? That's obvious. We want to hold onto the memories, to refresh them, to share them, etc. That's especially important to me because I have a terrible memory (fortunately, my wife is very forgiving).

But, why don't we do that on our software projects? Sure, we may have a company picnic and take pictures, but that's not what I'm talking about. Why don't we keep a project journal, take a "snapshot" of the brilliant insight that a co-worker had on a particularly tough technical issue, or record our team meetings where we made all of those important decisions? Sometimes, we do. Most of the time, we don't. We rely upon our memories, upon the memories of our co-workers, and in many cases, the *short* memory of our clients and customers.

The more I think about it, the more I think that there's not enough information about our projects stored somewhere that's long-term. It's hard to learn from your mistakes when you forget them so quickly (in fact, I tend to claim that I don't make mistakes; since I don't remember them, they didn't happen, right?). It's not that we don't have the tools (email server backups, wiki pages, blogs, shared storage, etc.). I'm not sure if it's a cultural thing (for geeks) or that no one shares my opinion that it's important. Maybe we never justify the time to write it down? If so, that's too bad, as I expect we lose a lot of time looking for information that was lost or forgotten. If I remembered everything that I ever did and learned, I'd almost be a half-way smart guy. Unfortunately, I didn't write it down, so I remain pretty dumb. Just forgive me if I have to ask your name a few times...

Wednesday, April 06, 2005

BBQ Grills

So there I was at one of those "very-big-home-improvement-stores" with my father-in-law. I was looking at barbeque grills. I enjoy grilling, as most males do, so I was "doing some research" on the one I'd like to get (when I can afford it). I already have one, but it's getting pretty old and miserable, so I was looking for an upgrade candidate.

They had grills that were really cheap, some that were really expensive, and lots in between. The price differential seemed to be based mostly upon the size of the grill (how many burgers do *you* want?) and features (can you say "rotisserie"?).

As I was inspecting them, I noticed something rather strange. There was a set of very nice ones that were basically the same, except that they ranged from smaller to larger (both in price and in size). It was one of those "series" things, where the manufacturer tries to hit several different price points. Nothing surprising or wrong about that. However, I noticed on the smaller/cheaper models that they used the standard "can" approach to catching the grease at the bottom of the grill. This was strange, since I don't think the approach is a very good one, especially when there are other alternatives that work as well or better (in fact, the top-of-the-line grill just had a slide-out tray). These grills with the "can" also had a slide out tray (out the back, instead of the front), but my concern was that they wouldn't catch all of the grease (grease sometimes goes out at an angle; wind blows the can around, etc.).

The strange part about it was that I'd found a cheaper model from another manufacturer that used a slide-in box (angle won't matter, and it doesn't get blown around), which I thought was pretty clever. I figured that if I spent so much more on the better model, it wouldn't have settled on a "can" approach. But, it did. (I should note, here, that there is a downside to the slide-in box: it'll be hot during and right after cooking, while the can won't.)

Looking back on that experience, I realized that it mattered to me which method was used because the maintenance of the grill mattered to me. In fact, I'll go so far as to say that that's one of the most important (if not *the* most important) features of a grill (to me). Why? Because I hate cleaning grills. So, the less work I have to do to keep a grill clean, the happier I am (and the more grilling I do).

It's all about what's important to you. Is it the number of burgers, etc. that you can cook at a time? Is it the amount and exactness of the heat? Is it the features, like having a rotisserie, a side cooker, and a built-in cabinet? Is it looks, mobility, or what? To me, it's the maintenance.

Programmers have the same question to ask: what's most important? Is it the speed of the code, the speed of the development process, the maintenance, the elegance, the framework used, or what? There may not necessarily be a right or wrong answer to that question (at least, not in a general sense). However, it's an important question to ask, and should be asked separately for each project. Different design or architectural decisions may be made because of it. For example, if it's speed of execution, you may lose some on the maintenance. The other aspect is that understanding your priorities allows you to counter-balance the decision with other processes. For example, if speed of execution is the priority, you may take extra care to ensure that the code is maintainable because you know that it tends to be forgotten. You may adjust your schedule to provide fewer features because you know it'll take you longer, etc. Understanding motivations allows you to adjust for them.

Certain types of grill surfaces require different kinds of cleaning materials or approaches. If you just don't pay attention, you'll be buying a new grill too often. You may buy the wrong grill. You may find that that cool-looking cedar-enhanced grill fades very quickly because you didn't keep it covered. If you don't care, then you don't care. Buf it you do and understand your motivations and priorities, you can adjust your behavior to suite the problem at hand.

Monday, March 14, 2005

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.

Monday, March 07, 2005

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.

Wednesday, March 02, 2005

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.