Bowling By Skill or Score

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

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

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

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

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.