Dan's Programming Paradigms

Of Course I'm Done, Can't You See the Wall?

2010-03-16T18:28:00.002-05:00

Across the street from where I work, they're putting up a large office building. We have lots of windows, so I sometimes gaze at the work going on there. Lots of big machinery, lots of people, and lots of progress from week-to-week. Sometimes, when I watch the big machinery "doing its thing," I wonder if I went into the wrong career. Nothing I do will look that cool.

I don't know anything about building houses, buildings or much at all. I did build a rabbit hutch when I was a kid. I've even put up a tent or two, though that usually required help from my wife. But, I've built software.

I was pondering, as I watched the construction of the building, how it must compare to building software. I imagined a large project schedule with all of the tasks that must be done, the dates and their dependencies, etc. I figure it must be pretty difficult to keep everything moving forward, ensuring that the right materials were on-site at the right time, etc. I started to think more about how it compares to building software.

Among other things, one of the more interesting differences has to do with the visual element. As a manager, how do you know that the software is "done?" Well, when the testing team says that it's done. But, that might be too late. Wouldn't it be nice to know from the developers when they're done building software? Of course...just ask them. But, what if they're wrong?

Though an obvious over-simplification, when building a house or even a large office building, when someone claims they're done, a quick inspection is all it usually takes (again, it's an over-simplification, as some parts of "done" are more complex than looking at a wall and saying, "Yup, I guess you're right...you finished the wall 'cause there it is!"). For software, that's not that easy. Some software is easier than others. Applications that are predominantly interface-related (i.e. desktop apps or web apps) are much easier because there *is* a visual element, though whether everything behind it is done or not is a different story.

Ultimately, testing determines whether the software meets the requirements. Newer methods of testing up-front or driving development via tests help to understand "doneness" sooner than later. Unfortunately, many projects are not that sophisticated.

Mowing Straight

2009-10-13T19:49:00.002-05:00

Here it is, another lawn mowing entry. It seems that we learn much from our dislikes...something about what doesn't kill us makes us stronger. Well, I don't feel stronger, but it helps with the perspective.

So, there I was, mowing, again. This time, I'm pondering how difficult it is to keep my lines straight. To be honest, I'm not even sure why I bother, given that no one really looks at my lawn besides myself.

Of course, the real reason is that it means less rework, and given how much I enjoy mowing the lawn, rework is definitely something that I work hard not to do... (um, right)

So, how do you keep your lines straight? I'm certainly not going to go get a plum line or buy some laser sight or something like that. So, I do it the old fashion way: pay attention to where I'm at and where I'm going.

I noticed something, though. If I concentrated on only where I was at, to ensure I was lining up with the last line, I tended to make more mistakes. However, when I looked out a little further, I tended to do a better job of keeping the line straight.

I've found that this works with helping to keep a project moving smoothly. If all you do is fight fires and concentrate on what's immediately in front of you, you'll make more mistakes, head off in the wrong direction and lose your perspective. Keeping some view of what's coming ahead and where you want to go helps keep things in perspective and ultimately improves quality.

Lawn Mowing and Estimation

2009-05-12T18:53:00.003-05:00

I hate mowing the lawn.

I was out mowing the other day and was pondering upon how much I dislike it. I really shouldn't hate it so much, since it's good exercise, it needs to be done, and it makes my lawn look nice (well, "nicer" would be more accurate), but I do. My pondering included thoughts of hiring a professional company and wondering how much it would cost me. I wondered how they would estimate the cost. You see, my lawn, though not necessarily large (well, *I* think it's large), is very hilly (welcome to West Virginia, they tell me).

I wondered how you would go about estimating the cost: whether by size or by time. The way I think, the biggest cost to lawn mowing has to do with time. Specifically, I would expect that it would have to do with direct labor cost (how long someone spent mowing) and how much gas was expended. For some reason, I focused on the gas aspect (given gas prices) and wondered about the best way to estimate its cost.

If you do it by size, it's pretty easy to estimate, given that you can visually estimate the size by merely looking at the yard, itself. However, if you estimate based upon the time it takes, it's easier to run into tricky mistakes. Looking at my lawn, for example, with all of its hills and crooks and crannies, you'd think it wouldn't be too hard. But, after mowing it, I found that it took a *whole* lot longer than I'd anticipated.

Programming is fairly similar when it comes to estimation, though I think the difficulty is flipped. It's difficult to estimate size, but easier to estimate time (at least for smaller tasks). Estimating size in lines of code, of course, depends a great deal on the language, the programmer, and the task at hand. Not all lines of code are created equal. Of course, there are other size tools, such as function points, use case points, complexity counts, etc. The concept is the same, but the measuring stick is different (not to suggest that any measuring stick will work just as well...hence the number of different measures). There are even complex mathematical models that use size to estimate larger projects, such as COCOMO (there are a number of commercial parametric estimation tools that use their own proprietary models).

Estimating time, at least for smaller tasks, is usually straight forward for a programmer with a little experience. But, then, that's been my experience. Time estimation for larger tasks, though, becomes much more difficult...just ask anyone who has had to fully plan out a large project using MS Project or similar tool. So, maybe it's not so different than mowing a lawn...

Either way you look at it, though, estimating helps to measure cost and effort, helping you know how much of that lawn you're going to finish before it starts raining for a week straight...

Don't Touch My Swiss Army Knife

2009-02-11T20:00:00.000-05:00

I got a Swiss Army Knife for Christmas (okay, it wasn't a "name-brand, trademarked Swiss Army Knife, but it had lots of blades and things...it was cool). Those things are cool. They have different kinds of knives, different kinds of tools (mine even has an LED light on it!), and maybe even a cool case. They're handy to have around when you need to do some cutting or sawing or snipping (if it has scissors) or whatever. It's great...

Unless, of course, you need to fillet a fish, skin a deer, saw a tree limb off, or cut up a cardboard box for your daughter so that she can make whatever it was she dreamed up. Then...well, it's not so handy. Then you have to go get "the real tool," whichever it is for the situation.

Of course, some people who get Swiss Army Knives use it, anyway. They use it to cut up their perfectly barbecued steak, or saw that tree limb (it's only a half inch thick...), or see how far they can throw it and still stick it in the tree, or even stick it under their pillows at night (okay, okay, maybe no one uses their Swiss Army Knife for any of those things...it's funny to think so, though).

It's just not the right tool for everything, but it *seems* like an *adequate* tool for nearly anything. And that's the problem.

At least, if it's a spreadsheet. That is, a spreadsheet is the "Swiss Army Knife" of the electronic world. It can be used as a database, a word processor, a calculator...I'm sure that it could even help you do your laundry. It's great for those simple jobs. But, it's amazing how it gets used for those difficult jobs. I'm sure you've seen them: a complete implementation of a general ledger, a metrics database, a process diagramming solution, a complete ad hoc reporting tool, a form processor, or whatever. I can't tell you how excited I was when I created my first pivot table...and I still don't really know what they are!

Sometimes, when you're all alone and you have a desperate need to cut something and all you have is a Swiss Army Knife, it's like a wonderful friend who you're glad to have along. But, sometimes...well, I think you know what I mean. Sometimes, you need the right kind of knife.

You can always keep the Swiss Army Knife in your pocket...it won't get lonely.

Discipline Enabling

2009-01-08T21:00:00.002-05:00

I've got lots of kids, so I know all about giving out 'discipline.' What I find is that, in general, it doesn't work so well. In some cases, a well-placed "correction" can go a long way, especially if the child doesn't really understand that they were doing something wrong. For example, sometimes, my kids will use inappropriate words. They may not realize that they are bad words (they're still pretty young), so when I point out that it's an inappropriate word, they don't tend to use it again. In other situations, correction doesn't work. They aren't too disciplined in many respects. One of them, which parents for many years have labored against to no avail, is keeping rooms clean.

One of the problems is that they have too much stuff and not enough places to put it. In other words, there isn't much more than just beds in their rooms (we have recently moved and didn't bring all of the furniture with us and haven't gotten around to getting more), which means that 'stuff' gets left all over the place. Not only is it difficult to expect them to keep it clean now, but they're getting in the habit of not cleaning it, which means that when we eventually get them the furniture to put it all in, it will take some time getting them into the habit of keeping things clean (I figure that their rooms will get clean when they move out of them and leave the house).

Which leads me to processes: specifically, software development methodologies and their associated processes.

One of the fundamental problems with any and all software development methodologies is the issue of getting the team to follow the process, whatever it is. Discipline, in this case, is whether the team, on an individual basis, is following the process. If they follow the process, they are considered well-disciplined. If they do not, well...they get 'disciplined' (okay, maybe not, but it sounded funny, anyway).

What typically doesn't get discussed much, which I think is a gaping hole in any methodology and a pretty big gaping hole in software development, in general, is this issue of being disciplined. I think the reason for this is that there's an expectation that, as adults and professionals, you shouldn't need to have a problem with being disciplined. And, in general, that's true.

I never took economics in college...not sure how I got away with that, but I didn't. However, I've always had an interest in finances, so eventually, I broke down and bought some basic economics books to learn a little about the topic. What I found was a fascinating thing: economics attempts to accept reality for what it was and provide some understanding around the financial side of it (please note the use of 'attempts' in that previous sentence...I'm not an economics expert, and I assume that many would not take that perspective based upon the economics classes they took). What I mean by that is that it has, at its core, the concept of incentives (it has other things as well, but they aren't pertinent to my point). Incentives has to do with motivation, decision-making, and pain (stick with me on this pain thing...). It had interesting implications for software development.

So what does economics have to do with professionals not following defined processes? And what does missing furniture have to do with my kids inability to keep a clean room? One word: enablement.

'Enable' is one of those cool words that everyone hates because it's a 'manager' word...it's not a four-letter word, so it's okay to use it, but it's one of those words used by managers to mean something that is important, but which no one understands (or, is too big for what it's being used for). It's like using the word 'dialogue' as a verb...it's wrong on so many levels, but it sounds cool to a manager, because it's 'big.' Of course, since I'm a manager, I get excited about these kinds of words...it's a chance to make fun of myself by using big words.

In this case, applying the word 'enable' to discipline means providing appropriate incentives to people such that they will have a greater degree of discipline, whether they like it or not. Putting furniture in my kids rooms won't solve the cleanliness issue, but it will enable them to do better (in other words, it may not mean sparkling clean rooms, but it should mean better organized rooms).

Even though adults and professionals shouldn't have a problem with being disciplined on a software development project, they sometimes do (and in some cases, it's a major problem). This is because there are incentives (or a lack of them) to do what they are doing. Rarely do people do things randomly. Economics tends to agree with the concept that water heads in the direction of least resistance (technically, water heads in the direction in which it perceives the most value or return for its limited resources, but that's not as easy to picture).

Let's use an example: let's say the process states that all code must be peer reviewed. You're working on a project that's expected to have a million lines of code and it needs to be written in about a year. You've got a big staff and a process that's primarily paper or spreadsheet-driven. Do you think every line of code will be reviewed? How about if each review requires at least three people, must have half a dozen metrics tracked, reported, and verified? I won't suggest that there are no projects in this situation that haven't had every line reviewed. I just don't think I'll need more than a hand or two to count them all.

What if I changed the process by creating a web-based tool that allowed code to be reviewed asynchronously, which automatically tracked all appropriate metrics, etc.? Do you think there would be a better chance? Did you know that such a tool exists (it does, by the way...many of them, in fact)?

When you make something easy; when you smooth out a rough or painful process (there, I got back to that 'pain' thing); when you hide following a process by merely using a tool to accomplish something that you had to do manually before; when you make process a part of doing your job, rather than an external thing to be followed, it will get done more often. It may not completely remove the lack of discipline, but it will go a long way towards overcoming major discipline issues, if not fixing minor ones. You never know, it might save time and energy, raise morale, create better quality products, cure diseases and encourage peace on earth (okay, maybe not so much about the disease and peace thing, but, hey, those are good goals, too).

Just remember that a tool does not necessarily mean something physical or electronic (i.e. web site, development tool, etc.). It might mean providing decision authority to the right people, adjusting an organizational chart, letting people work from home more often, or merely bringing in a ping-pong table and seeing what happens...

Ramp It Up

2008-09-18T19:18:00.002-05:00

I've been noticing lately, and it may have to do with the new location I moved to and my new commute, that it's fairly common for people, as they get on the interstate, to not fully utilize the on-ramp.

Here's the idea: you need to get on the interstate. It's a major freeway, traveling at high speeds. There's this "on-ramp" that's to be used to speed up to sufficient speed to appropriately merge with the rest of the traffic already on the freeway. The whole point of this is to prevent the need to put stop signs or traffic lights on the freeway (thus, increasing the speed and throughput of traffic). There's nothing new here, as these freeways and the on-ramps have been in existence for decades.

So, why is it that many people don't fully utilize them by "getting to merge speed" before attempting to merge with existing traffic? Too often, I've been stuck behind a car trying to merge that's going much slower than needed, which causes them (and, since I'm behind them, me, as well) difficulty in merging (in some cases, causing a very dangerous situation). It's frustrating.

It's like in development, where you're working with a team, and you're dependent upon some code, interface, module, or whatever from another developer. This developer may be fast or slow, but if their work was properly planned out, it was to be delivered to you by a certain date or time. But, because they figured they had plenty of time, they lazily worked toward completing their task. I guess they figure they'll get it done, but when they don't, their surprised. It ends up messing up your own schedule, and could potentially cause some serious delays in the overall project. Why didn't they accelerate appropriately so that they could safely merge? Why didn't they work hard, right off the bat, making sure they were well ahead of schedule (or, at least, well on schedule)?

It's just downright frustrating.

And they wonder where coding rage comes from...

Sometimes, You Just Have to Start Over

2008-04-26T19:07:00.002-05:00

I have no sense of direction. That basically means that I get lost easily (of course, with the new GPS device that I just bought, I should be okay). So, sometimes, when I take the wrong direction, I have to back-track to a known location and "try again." Of course, getting back to a known location can sometimes be difficult.

The same goes for reading: I love to read, but sometimes, my attention wonders. That's kind of embarrassing when you're reading (the good thing is that, usually, nobody notices). But, it happens: I'm reading along and realize that I don't understand what's going on in the current paragraph because I wasn't paying attention in the last couple, so I have to go back and figure out how I got there.

Same goes for building things. If you build a paper airplane, and you get one of the folds slightly off, most of the rest of the folds will get messed up, which means poor performance when you launch the thing. I hate that; especially when I'm trying to impress one of my kids with my great airplane-making skills (I have none, but they don't know that...at least, not yet).

The same goes for programming. After receiving a few enhancement requests for my open source project (iScreen at i-screen.org), I realized that in order to do some of them, it would take more than just a quick patch or added code. I'd have to revisit some of the basic approaches I took with the project. So, sometimes you have to just start over.

Of course, not literally. There's no point not leveraging what you have that's good (if you can). So, I won't have to rewrite the entire framework from scratch, since I'll be able to leverage most of what's there. But, I'll have to "start over" on some of the basic approach. Ouch. Guess that airplane's performance wasn't as great as I'd hoped.

The Opportunity To Fail

2007-10-30T19:03:00.000-05:00

Usually, I try to build my post from unrelated experiences. However, sometimes I just need to comment and to provide what I consider to be insight. This is one of those times.

Now that I'm in management, I have to choose my "style." Many managers like to control and dictate; others like to keep their hands off. I tend to be a little of both. One aspect of my style has to do with failure. I believe in giving people the "opportunity to fail."

The opportunity to fail implies the opportunity to succeed beyond my expectations. And that's the real motivation. But, why put it in terms of failure? Why not say: "opportunity to succeed?" That's an interesting question and the point of this post.

However, before discussing the failure versus succeed issue, it's important to understand the implications of the "opportunity" part. I believe in giving people a chance. On the flip side, I think it's inappropriate to drop someone into a lake to teach them how to swim. You might consider that an "opportunity to fail" (and, in a sense, it certainly is, since there's a good chance that they will fail and drown), but I don't. It's not an opportunity because they haven't been given the tools that they need to succeed. You don't really lose a race when they tie you up and make you crawl...it doesn't "prove" anything.

"Give them enough rope to hang themselves." Or, "When you're at the end of your rope, swing." They mean the same thing. One is a positive outlook (swing!), and the other is a more negative approach. Why approach it from a negative view?

Developers like challenges. Tell them one way and they'll find another way (as long as it's their way). Posing a negative approach challenges them to prove your wrong. It's the resistence training that they need to build their ego. I like the analogy of computer games. If you're playing Doom or Quake, you can always use the cheat codes to get through, but it's not nearly as fun. It's more fun because you know you can fail (get fragged).

So, I let 'em fail. But, I gently remind them to "impress me" if they can. Sometimes, I'm surprised at how well they can impress. Typically, they succeed, but just barely. Sometimes, they fail. When they do, I make sure to help them learn from it.

You Take the High Road, I'll Take the Low Road

2007-09-11T17:00:00.000-05:00

I was pondering on my commute home today about different types of developers that I've run across in my career. I came to the conclusion that there are basically two types of developers (major disclaimer here: I'm over-generalizing this, obviously, so don't be too critical of the narrow-mindedness of this post): those that need to "go deep" with a technology or concept--the "deep diver," as I call them; and those that love to play with all sorts of technologies, collecting them like sea shells on the sea shore--these I call the "tinkerers".

There are various shades of these two personalities. For example, some "deep divers" like to *really* go deep on a particular technology, to the exclusion of pretty much anything else. These people are sometimes referred to as "fanatics." Others just like to spend enough time on the technology such that they feel that they've mastered it (not just "good enough" but "right enough"), and then move on to another that interests them. These tend to specialize in related technologies, languages, or concepts.

Some "tinkerers" may just love to play with technology, never really learning to use it beyond piecing it together. I've noticed that they really like scripting languages like Perl, Python or Ruby (not that there are no deep divers that like these languages). Others "learn enough" to do what they need to do and move on. They tend to have a broad background across many technologies, but have never truly mastered any particular one.

Rarely do you run into anyone that would come close to fitting in to both groups. The reason for this is simple: there's just too much "stuff" to learn, see, or play with. Many consider themselves to be a hybrid when they really are a "learn enough" tinkerer, since they don't "see" the depth that they are lacking. Others feel that they have a broad background when they know only a language or two and have worked with a small handful of libraries, but have mastered these extensively (typical mindset: "...this is how you should do that because that's how it's done here, and there's no better way of doing it because this is the greatest technology...").

Is being in one group or the other better? I don't think so. What puts us into one or the other is based upon interest. We go where we find "interesting things." For some, that means diving into a particular topic and really understanding it. For others, it's viewing the grand landscape that is the information technology industry. However, taking one of these to an extreme (too deep to exclude all else, or so broad that you don't really understand what you learned) is probably not appropriate.

Does knowing which group you're in matter? Is understanding that there are two types of personalities matter? I think so, and here's why: if I could convince someone who believes that "technology/language X" is the best solution to whatever problem is before them (when you have a hammer, all problems look like a nail) that there are *many* possible solutions (many of which could do the job just as well or better), then I've made them more humble and a better practitioner of the art. I wonder how many technological errors are made because the decision was made by someone who couldn't see deep enough or broad enough to fully understand the possible solutions.

Unfortunately, we're all human and at this stage in the industry's maturity, there's no way that a single person can know and understand (to a sufficient depth) all the possible solutions and tools available to apply to a particular problem set. We all work with limited knowledge. The goal is becoming humble enough to be open to new ideas and courageous enough to go deep when it's time to really understand something.

(By the way, I'm a "deep diver" type.)

Juggle This

2007-08-17T20:08:00.000-05:00

I'm in a management role where I work, and though it's certainly not as difficult, technically, as what I was dealing with as a developer or architect, it's more difficult in other ways.

Certainly, the people-aspect of it is the most challenging, but also the most rewarding. What I didn't expect, and this may have less to do with management and more to do with my specific responsibilities, is the amount of pure "juggling." There are so many things to keep track of.

Development requires a certain amount of deep concentration and focus. Developers that are hounded all day about anything rarely have time to actually get work done. In my current position, it's been more about tackling a lot of different things (i.e. follow-up with this person on this issue; check to make sure that this task was done; review this or that work; go chat with person X because they look like they're having a bad day; etc.), with little time to focus on a particular task.

It's about juggling.

When you learn to juggle (and, as an interesting sidebar, learning to juggle can be a fascinating experience, if you think about what is necessary to learn), you have to learn to not only coordinate throwing and catching...you have to, internally, accept the possibility of dropping something. At least, initially, you accept this. Ultimately, you gain the confidence necessary to actually be successful by finding out that you can actually do it.

Here's the drill: take two juggling bags and throw one up and over to your other hand (which has a bag). At it's peak, throw the bag from the other hand, but don't concern yourself about catching the first throw. More than likely, you won't, but that's okay because it's more important to throw the second bag correctly. This drill is the most important in learning how to juggle (it's not the only one, though).

I'm finding that I'm going through a similar learning process with my movement into management. Some days I rarely sit at my desk; others, I rarely get away from it. In either case, it's tracking down and dealing with many small tasks that, ultimately, keep the overall show entertaining.

Bowling By Skill or Score

2007-07-31T18:41:00.000-05:00

We had a team outing a while back in which we invited my team and their families to an outing of bowling. I'm not a great bowler, though I actually took a class on it in school and even got some one-on-one time with a skilled bowler at one time. So, though I don't bowl that well (nor that often), I do know *how* to bowl.

My wife, on the other hand, doesn't know how to bowl, doesn't bowl well, and doesn't bowl often. So, at the very least, I know better. Unfortunately, that didn't help me much that night as she beat me (though I might add, barely).

Now, I learned how to throw a hook, how to place it properly in the available pockets, etc. My wife was unaware of these, as she just let it go down the middle. But, she still beat me. In my defense, I'll repeat that I don't bowl often (about as often as my wife, which is next to never). But, I should know better. She still beat me.

Did I mention that she still beat me? Good. I thought I had. And that got me to thinking. What does it matter that I know how if it doesn't prevent me from humiliation in front of my co-workers? You see, it wasn't just my wife. My eight-year-old daughter *almost* beat me (can you see me hiding my face?).

So, I got to thinking about this. Anyone can pick up a ball and throw it down the lane and hope for the best. It's not that hard to pick up a language and throw some code together. It may seem that an inexperienced person can code just as quickly as a more experienced one. What about the proper process being followed during a project? There are plenty of successful projects that don't follow any known process; in fact, they're typically pretty haphazard.

I don't have an answer (other than I was out of practice) other than to believe that, over time, you'll have more successes when doing it "the right way." Having the right experience or following the process or bowling...eventually, the "right way" will win out (my best bowling score is still a lot higher than my wife's). Over time, a properly trained and intelligent developer will learn better, get better, and do better.

That's why there's technique... It's a "technique" because it was found that doing it that way "worked better." Just don't lose sleep over those times that it doesn't (and try not to be embarrassed that your daughter might almost out-bowl you).

Designing Software Development Methodologies

2007-05-09T19:40:00.000-05:00

As a side note to my normal entries, I wanted to mention a website that I've started that explores a new/different approach to software development methodologies. The site is at www.methodologypatterns.org. At this site, I put forth the opinion that methodologies should be designed, not necessarily pulled off the shelf.

Not only should they be designed, but it's important to go back to "first principles" in understanding what a methodology is and how it should be designed. The idea behind the methodology patterns is to first advocate for methodology design, then define the first principles from which to perform that design, and then to provide a library of practices to use and patterns of those practices to piece together a viable methodology. See the site for details.

My Pumpkin Can See

2007-01-22T20:30:00.000-05:00

Since my kids are pretty young, when it comes to carving the pumpkin, they do the "drawing" and I do the "carving." I think it has to do with all that "gunk" inside...that, or the sharp knife thing.

Well, I was working on one of them while my daughter looked on, making sure that I "did it right." Of course, I wasn't, because she told me so. You see, carving circles in a pumpkin, especially small ones, is *really* hard. I didn't have a professional pumpkin cutter (you know, those cute little orange-handled things that work like a saw), so all I could do was carve straight lines, and then "adjust" things to make it look more like a circle.

Of course, my daughter noticed that my cuts weren't going to work, since they were "straight" and she wanted "round." I had to explain to her that I was getting there, that they would look like circles when I was done. She didn't believe me, because she couldn't "see" it.

It reminded me of sculptures. You know, those artists who can take a rough piece of wood, whittle it down into a masterpiece, and you've no clue what they're working on until they're nearly done. You just can't see what it is that they see.

I feel like that happens with programming. Sometimes, it's difficult for others to "see" what it is that you're trying to accomplish. It's hard to describe, but you know what you're trying to do. You just have to show them the end results and hope they appreciate what it took to get there. The perception is that it shouldn't be that hard, because it's just a simple web site, or a simple GUI, or something like that. They could probably do it in a couple of days, while you're claiming it'll take weeks, if not months. They just don't appreciate what they can't see.

It's a good thing my pumpkin can now see, 'cause otherwise, my daughter would have made me buy her a new pumpkin and start all over. I don't like the "gunk," either.

It's All About the Fundamentals

2006-10-10T20:19:00.000-05:00

I was out shooting around at the basketball hoop in my driveway and noticed how poor my shooting had become. I used to play quite a bit of basketball, and though I never considered myself all that great, I certainly kept up. However, I've not played seriously for many years (kids'll do that to you), and it was obviously showing in my performance that day (luckily, no one was watching).

So, what did I do? Other than lament for the "good old days," I stopped and paid attention to what I was doing. I remembered learning all those fundamentals when I was a kid...how to hold the ball, how to release and follow through, etc. I'd not forgotten them, though my hands had.

And to my surprise, after some concentration, I was making noticeable improvement. Hey, I'm not so bad, after all! Of course, it wasn't like I was hitting every shot or anything, but my focus and concentration on the fundamentals had obviously helped.

And so I'm reminded of my own programming experience...those times when I've "walked away" from it, forgetting and losing my touch, only to return and, luckily, remembering the fundamentals and picking things back up. I'm reminded of watching struggling programmers who never learned the fundamentals, and how they struggled over issues that they would not have, had they stuck to the fundamentals. It's all about the fundamentals.

Solitary Sport, Team Play

2006-07-03T14:26:00.000-05:00

Programming is typically viewed as a solitary sport. That is, programmers are sent off into a cube, given their tasks, and emerge when the work is done. Obviously, a team exists, and get-togethers are common (sometimes too common). In some of the more agile environments, programmers are teamed together in pairs.

Recently, I spent some time "away from home," starting a new job (with the family to follow). I found myself, alone, in a apartment, with my evenings unadorned of family things: dinner, play, or any of the typical family-related evening activities. Did I mention that I was alone?

Great, I thought, I'll have plenty of uninterrupted time to work on some projects. I had plenty to do, lots of time to do it, and absolutely no motivation to get started. I found out something very interesting: it's hard to get motivated when you're the only one in the room (or whole apartment, in this case). I've not worked as a sole programmer on a project, so I'm not sure how they get motivated. However, I realized how important it is to put a team together and keep them together. They play off each other; they require each other to be "near" (even though they may not constantly communicate); we are a social animal, even when we work.

Watching the World Go By

2006-07-03T14:16:00.000-05:00

I typically work while I eat my lunch. So, there I was, sitting at the restaurant eating lunch, working on something or another for work. As I like to do while I'm eating lunch in this way, I look up and watch...I watch people, things, and generally let my mind wander a little. I've discovered that this is an amazing thing.

You see, I remember watching Dead Poet's Society with Robin Williams. He was an English teacher, and one day, he had the entire class climb up on his desk (one at a time, of course), take a quick look around, and then jump down. The idea was to give them a different perspective on life. It's about taking the time to see what's going on around us. It's also about seeing things from a different perspective.

That's why I like to move around while I do my work. Since much of my work requires considerable thinking, it's important that I give my subconscious mind the time it needs to sort things out. And I've found that when I "wander," I'm able to see things differently. Sometimes, that makes all the difference.

Programming is a thinking-man's game. It requires deep and focused thought. And, I believe, it also requires variation, perspective, and time.

The Snowfort

2006-03-29T12:24:00.000-05:00

This past winter, I was out in the snow playing with my kids. We were building a snowfort. My wife had come up with a great idea on how to go about it: use some small tubs to pack the snow into and up-end them as "snow bricks." So, there we were, up-ending our tubs of snow and stacking our "bricks" to make a snowfort.

Then I realized a problem: the brick idea was great, but there wasn't anything holding the bricks together. Not being a mason, I hadn't put a whole lot of thought into our structure. However, it became fairly obvious to me after we'd put up several rows of bricks that we needed some mortar. So, I switched everyone to stuffing snow in the cracks.

Once caught up with mortar, I went back to bricks. However, a couple of my kids kept at the mortar work. With so many on the mortar, the brick building was going slowly (I'm getting old). Hence, I asked my "mortar" kids to help with the bricks. They refused: it was too hard of work and they kept at the mortar work.

I got to thinking about this impasse: they didn't want to help with the bricks, but that was the whole point of the exercise, to build bricks and build the snow fort. The mortar was certainly necessary, but didn't require all the extra time they were putting into it (though the snowfort was definitely solid, given the amount of mortar they were putting in).

In building software, it's important to add the "filler" to make sure things run smoothly (the development methodology and its related practices), but if you concentrate too much on it, you lose focus on what you're doing: writing code. Writing code is hard work, but it's the fundamental aspect of producing an application. The "mortar" of software development helps to keep it together (and keeps it from falling to pieces), but there's a limit to what help it can provide.

Of course, given our poor choice of location, all the mortar in the world wasn't going to help us when the sun came out. If we'd been at the North Pole, we'd have been okay.

Fish

2006-02-02T08:23:00.000-05:00

We bought fish. Not for dinner, but for an aquarium we got for Christmas. We bought four goldfish, thinking that those would live the longest and be the easiest to tend. They all died a couple of weeks later. We're not sure why.

We did some homework and research before we bought. We bought the starter kit aquarium. We asked the pet store people. We tried to be informed. But, sadly, we're not experts. So, they died.

One of the things that I learned from this is that not everyone has the same opinion or information on how to care for fish. The kit said one thing; the books said another; and the people at the pet store said something in between. Unfortunately for our fish, we must have listened to the wrong information (or, possibly, misinterpreted it).

Now we have dead fish, an empty aquarium, and some sad little kids.

Shhhhh. I'm Hiding

2005-08-19T05:00:00.000-05:00

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...

The Movers, They Come

2005-08-09T05:00:00.000-05:00

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.

On and On

2005-06-06T05:00:00.000-05:00

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.

Concentration

2005-05-04T05:00:00.000-05:00

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.

Out Of Shape

2005-04-26T05:00:00.000-05:00

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.

Memories

2005-04-19T05:00:00.000-05:00

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...

BBQ Grills

2005-04-06T05:00:00.000-05:00

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.

Tool Specialization

2005-03-14T06:00:00.000-05:00

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

2005-03-07T06:00:00.000-05:00

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

2005-03-02T06:00:00.000-05:00

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.