Friday, December 30, 2005


Risk and Honesty

I arrived at the helicopter school about fifteen minutes early for my discovery flight, so I had some time to kill. This school is also a Robinson dealership, so the waiting room had a lot of marketing material scattered around. I picked up a reprint of an article from Flying magazine about the history of the R22 helicopter.

The R22 was originally designed as a low-cost personal helicopter, but was quickly snatched up by flight schools shortly after it was introduced. The combination of student-pilot use and low-experience instructors resulted in an appalling fatal accident rate. Robinson made some changes to the helicopter design, and also insisted on changes to training procedures and regulations, and the result has been increased safety.

This article was being reprinted and distributed by Robinson. They were rightfully proud of the fact that they had identified problems and improved their product, and believed that potential customers would find it reassuring. As a pilot, I really like that approach, but I was amazed to see a company using it.

In contrast, can you imagine going into a car dealership and seeing a pamphlet that says, essentially "A bunch of people died in this model of car, but don't worry, we've fixed it." No. The car industry doesn't work like that. They would deny that any serious problems ever existed, and if the evidence is impossible to ignore, then they would either stop making the product or re-market it under a different name.

Pilots are different from most people. Pilots understand that there is always risk. Pilots actually want to know what might go wrong. They aren't interested in being able to deny that they knew about problems, and they aren't interested in finding someone else to blame.

I wish there were more people like that in my line of work.


Introductory Helicopter Lesson

366 days ago, I had my first flying lesson in an airplane. Today, I took a lesson in a helicopter. I want more.

My foray into aviation started with radio-control helicopters. After spending hundreds of dollars on replacement parts, it occurred to me that flying a real helicopter might cost less per hour. I did some research, and settled on fixed-wing aircraft instead of helicopters due to the lower cost and greater practicality. But I've always retained the interest in helicopters.

The lesson started with a bit of ground school. SFAR 73 to Part 61 of the Federal Aviation Regulations requires that no person may manipulate the controls of a Robinson R22 or R44 helicopter unless they have received training in a few specified subject areas. It took about five minutes to cover these things. Then we walked out to the helicopter.

The school offers training in both the two-seat R22 and the four-seat R44. The combined weight of the instructor and myself was over the 400-pound fully-fueled payload limit of the R22, so we took the R44. As with my first sight of a Piper Warrior, I was surprised at how small it looked up close.

We got in, and the instructor started the engine, then explained the controls to me as the engine spun up. There are two pedals on the floor, which control yaw as in an airplane, a joystick-like control called the "cyclic" which controls nose pitch and roll, and a lever called the "collective" which controls up-down motion. (For all you helicopter pilots: yes, I've simplified things greatly. I don't need you to correct me.)

The instructor got the helicopter hovering a few feet off the ground, then taxied over to an open grassy area used for hovering practice. He started my training by letting me control the pedals while he handled the other controls. I've never been really good with the rudder pedals in an airplane, so I wasn't expecting to do very well with this, but it wasn't that bad. The helicopter pedals are very sensitive in comparison to those of a Warrior. Just a little bit of pressure was enough to keep the helicopter pointed where I wanted.

Next, he let me use the collective to maintain altitude a few feet off the ground, while also using the pedals. Things start to get complicated here, because whenever you move the collective, it changes the torque produced by the engine and so you will start spinning unless you press on the appropriate pedal to compensate. And when you press on a pedal, your altitude changes, so you have to move the collective to compensate for that, which changes the torque so you have to compensate with the pedals, and so on, and so on.

Finally, he let me take the cyclic, where things really started going haywire. An airplane is naturally stable—you can take you hands of the controls, and it will tend to return to straight and level flight. In contrast, a hovering helicopter is naturally unstable. One must constantly make little corrections to keep it upright and stationary over the ground. I mastered this with the R/C helicopters, but that experience didn't help much with the full-size helicopter. With the tiny toy helicopters, control changes happen very quickly, but with the big helicopter, it takes a few seconds to see what happens after moving the stick, and by the time you see what's happening, you've gone too far and have to start going in the opposite direction.

The cyclic didn't feel right to me. Most helicopters have a cyclic stick between the legs of each pilot. In a Robinson helicopter, it's a little different. There is a stick coming out of the floor between the two pilots, and then a "T-bar" which puts a handle in front of each pilot. The center of the T-bar pivots at the top of the stick. This leads dumb fixed-wing pilots like me to subconsciously try to turn it like an airplane yoke.

So, for a few minutes, the instructor would give me the controls, I'd keep the helicopter somewhat steady for a few seconds, then would lose control and he would take the controls back. It was fun. I didn't expect to master it my first day. I was improving with each attempt.

We also did a couple of "teardrops," meaning that we flew away from the airport about a mile, turned around, and came back in for a landing. It's a lot simpler and quicker than the rectangular patterns that airplanes fly to practice takeoffs and landings. Takeoffs were easy: just raise the collective and push the cyclic forward a bit, and you're on your way. Once you get moving, you don't have to worry about the pedals, because the tail acts like a weathervane, keeping you pointed in the right direction.

Making a low 180-degree turn in the helicopter was unnerving at first. In an airplane, going low and slow is dangerous, and making a sharp turn in that condition can be suicidal. But the helicopter is always going low and slow, and one need not worry about stalling or spinning. The instructor kept telling me to increase my bank, and I did, but there was a voice in the back of my head screaming at me the whole time.

Flying a couple hundred feet in the air at a slow speed was pretty cool. In the airplanes, we're always at least a thousand feet up when we aren't taking off or landing. At the lower helicopter altitudes and lower speeds, you can see people and other details that aren't visible at traffic-pattern altitude.

A Cessna on final approach passed a few hundred feet over us while I had the controls. The instructor pointed his index fingers at it and made machine-gun noises. That's exactly the same thing my airplane instructor always did! I guess that's something they teach in flight-instructor school.

A helicopter landing is a lot different from an airplane landing. You just slow down and descend until you are a hundred feet up and just downwind of the helipad, then you slowly descend. It's a lot easier to make a soft landing. Parking is a lot easier too: you just hover over to where you want to be, then touch down. No towing needed.

So, it was great. Will I take lessons and get a helicopter license? I don't know. Right now, I think the time and money would be better spent pursuing an airplane instrument rating. Also, I should lose about 30 pounds so that I can take lessons in the $200-per-hour R22 instead of the $400-per-hour R44. So I don't think I'll be taking helicopter lessons in the near future, but may do so later with those other things out of the way.

But there's a part of me that really, really wants to learn how to hover. Right now.

Monday, December 26, 2005


Enough With the Digital Imagery, Already

I went to see King Kong tonight, and walked out at around the halfway point. It wasn't horrible, but after watching the big dinosaur-tumbling scene, I decided I just didn't want to sit through another 90 minutes of big computer-generated animals.

I didn't mind the computer-generated stuff in Jurassic Park, or in the Star Wars or Lord of the Rings movies. I think Jurassic Park worked for me because it had computer-generated dinosaurs in the middle of real scenery. Star Wars and Lord of the Rings worked for me because they had fantastic creatures in fantastic landscapes.

But with King Kong, we have realistic computer-generated creatures over a realistic computer-generated background, supposedly happening in the real world, but the overall effect is not realistic at all. None of it is realistic enough to let me pretend I'm watching something real. It's all a big graphics demo.

Maybe I'm hopelessly old-fashioned, but I prefer the old-fashioned physical-model-based effects over the computer-generated ones. They just look more real to me. The computer stuff is "cool," but fake. There's a blurriness and smoothness to it all that just doesn't work.

To be fair, I left before seeing much of Kong himself. He doesn't show up until an hour into the movie, and the filmmakers are very coy about showing too much of him too soon. From the reviews I've read, I understand that he and Naomi Watts have some very touching moments. But I wasn't willing to wait.

I'm sure I'll see the rest of King Kong eventually. I hear it is pretty good. But right now, I'm in the mood to watch King Kong vs. Godzilla, with the people in rubber suits. That's a real monster movie.

Wednesday, December 21, 2005


Avoiding Noise

Earlier this year, I bought a pair of Bose QuietComfort 2 headphones to try to eliminate noise in cubicle-land. I occasionally listen to music with them, but usually I just wear them unconnected, to cancel noise.

This has worked fairly well, but there are a couple of drawbacks. First, they are great at drowning out background noise, but do little to silence conversations and ringing phones in adjacent cubicles. Second, there is a buzzing noise whenever my Blackberry or a nearby cellphone perform wireless communications.

I was recently given a wireless modem to add to my collection of junk that I constantly need to test, and now the Bose headphones are buzzing all the time. I decided I needed a lower-tech solution.

I picked up a pair of protective earmuffs at Home Depot, and they work pretty well. There is no buzzing, and they block out all sounds, not just what Bose thinks of as "noise." The only drawback is that they squeeze my head pretty tightly, because a tight seal is needed to block sound.

I've considered wearing my aviation headset to work, as it has a higher noise reduction rating than the earmuffs, but I think I probably look silly enough already.

I've been offered a real office (with a door!) a couple of times, but have wanted to stay in the cubicle so that I'll remain close the people I work with. I'm not sure I'll maintain my resistance; the next time I'm offered an office, I'll probably take it.

Tuesday, December 20, 2005


There Is Only One Answer

Kris, we understand you want the test system re-configured for some reason. Please explain.

I want the test system to work the same way that the production system does.

OK, which version of the software do you want installed?

I want the test system to work the same way that the production system does.

Do you need any data in the database?

I want the test system to work the same way that the production system does.

Do you need user accounts set up?

I want the test system to work the same way that the production system does.

Do you need the security system activated?

I want the test system to work the same way that the production system does.

Should we set up a modem for dial-up access, or is it OK to access it over the LAN?

I want the test system to work the same way that the production system does.

Should we just copy everything from the production system to the test system?

I don't care how you do it. I just want the test system to work the same way that the production system does.

Saturday, December 17, 2005


Where Should I Send It?

I'm not making this up. I received an e-mail that actually included this sentence:

Your resumé looks like a good fit for our opening.



It's Peanut Butter Jelly Time

Friday, December 16, 2005



Kris, the production system isn't working since we installed the newest release. Can you fix it for us?

Did you test the new release before putting it into production?


Did you install the server-side updates?


Other than installing the new version, did you keep everything else the same?

No, we changed a few other things too.

Can you send me the log files?


Will you let me access the system myself to see what's going wrong?


OK, can I access the test system to see if it exhibits the same behavior as the production system?


Are you sure this "new" problem never occurred with the previous release?


Can you roll back to the previous release?


Well, Kris, can you fix it?

Thursday, December 15, 2005


Zoom Modem Hell

Early this week, I was asked to take a look at some last-minute issues with a system that was to go live next Monday. "There are just a couple of minor issues," they said, "so we expect everything to be ready to go by the end of the week."

I took a look at the list of outstanding issues, and there was only one show-stopper bug, which I fixed in about ten minutes. I sent that fix off to the Quality Assurance department, confident that there would be no pressure for the rest of the week, because the remaining issues were minor and wouldn't affect any decision to deploy.

Then I tried to use the modem.

It turns out that the modems installed on these systems don't work. None of them. We have a warehouse full of machines with non-functional modems.

During development, we tested with a particular model of modem. However, it turns out that the production systems contain a different model, which requires different driver software. Nobody told the software developers. We didn't find out until this week, when Kris tried to get his modem working. Surprise! It's always exciting to find something like this the week before go-live.

"OK, so maybe we can just install drivers for these different modems," I think. I download the drivers from the manufacturer's site, and try to install. The installation program crashes. Hmmm. So I track down a CD-ROM that contains the drivers, and run the setup program from there. Again, the installation program crashes. We can't install the drivers for these modems on our systems.

I contacted the modem manufacturer's tech support department, telling them I tried running the installation program from both the CD-ROM and after downloading from the web site. Their response 24 hours later: "Try downloading the installation program from the web site." They clearly had not read any part of my e-mail other than "The setup program crashes when I run it."

I send them another e-mail, and the next response I get is essentially "Well, it worked for me when I downloaded it and ran it. Try running a virus scan." That's tech-support code, which really means "F**k off, idiot." In return, I'll warn everyone I can to not buy anything from Zoom Telephonics. (For the search engines: Zoom modems suck. Zoom bad. Zoom crap. Zoom blows. Zoom evil. Zoom technical support poor.)

The really frustrating thing is that installing drivers really amounts just to copying a couple of files and setting some registry entries. Their fancy-but-buggy setup program isn't really necessary. If Zoom would let me talk to one of their engineers, we could probably resolve this in half an hour. But the profit they make from a couple hundred modems isn't worth it. They would rather let Brian The Minimum-Wage Tech Support Guy spout canned responses back at me.

Meanwhile, I'm fielding phone calls and e-mails from pissed-off managers and co-workers wondering why the hell nobody tested this before, why can't we get it to work, who's responsible for this fiasco, what can we do now, and so on, and so on. I'm wondering a lot of these things myself. I had no involvement with this project before Monday, so I don't know the history, and can't accept any of the blame or point any fingers.

So what do we do? The first plan was to replace the "bad" modems in every machine with the "good" modems that we used during development and initial testing. Unfortunately, the "good" modems went out of production about a year ago, and we can't buy them any more. We need to find another model of modem that will work. This shouldn't be difficult, but it will take a couple of days to identify one and then get a quantity of them shipped. The deployment will be delayed, which will be both embarrassing and costly to the company.

The lesson to be learned is that it is important to test software with the actual hardware that will be deployed. It's a familiar lesson, which I'm sure we will learn several more times. The other lesson is that buying the cheapest modems you can find may not pay off.

I can't believe we still have this much trouble with modems. Modems have been around for decades. You'd think we would have mastered them by now. But the modem manufacturers keep producing new models each year, ceasing production of the old ones, and so we have to keep "upgrading." Why?

UPDATE (2005/12/19): Received this from Zoom Technical Support:

We have not heard from you concerning your request for support in the 72 hours since we sent you a response. Consequently, we have changed the status of your question to SOLVED.

Thanks Zoom.

Wednesday, December 14, 2005


Domain Knowledge

As I returned to full-time work, I noticed that my new salary was significantly larger than it was before I went part-time. I hoped that this was just an accounting oversight, but it turns out that it was due to one of those dreaded "promotions" that I am constantly trying to avoid. After talking with my boss, I discovered that I would again be leading development of a new product. As usual with such endeavors, I will start out knowing very little about the domain, and I have no idea how to do what I am assigned to do.

Among computer people, "domain knowledge" refers to the stuff that one's software is supposed to help its users do. For example, if you are developing accounting software, "accounting" would be the domain. If you are developing software for robots, then "robotics" is the domain. While there are common software-development skills that apply to all domains, every domain has its own unique characteristics, and learning more about the domain will make the developer more effective in solving the users' problems. Knowing about the domain also helps one in guessing what sorts of problems will crop up. Unfortunately, software developers often have to work on systems where they do not understand the domain, which leads to a lot of misunderstandings and a lot of frustrated users who can't figure out how to get the system to help them do their jobs.

In this case, the domain is "racing," meaning horse racing, dog racing, and other sports where people gamble on the outcomes of races. I barely understand what win, place, and show mean, and I have no idea what a perfecta, trifecta or superfecta is, so I have a lot to learn. Fortunately, I will be working with people who do know what these things mean.

So, for the next few weeks, I will be leading meetings and pretending to know what I'm talking about. With any luck, I actually will know what I'm talking about some time before the system goes live.

Saturday, December 10, 2005


Underwear Rotation

A really funny domestic-bliss story linked from jwz: Underwear Rotation.

I have to admit that I do rotate my bath towels, and the cushions on my couch. But I don't need to rotate my underwear. Why? Because the only time I do laundry is when I'm out of clean underwear.


Nixie Clocks

When I saw that jwz wanted a "nixie clock" for Christmas, my first guess was that it might a clock with the face of some sort of woodland faerie. But it turns out that a "nixie" is an electronic numeric display element that was popular in the 50's and 60's, then disappeared quickly when LEDs came around in the 70's.

It seems that some artist-engineers have been building clocks with these things. Check out the Nixie Clock Gallery for some examples. The pictures apparently don't really do justice to the actual devices, as you can't see the cool neon glow, and don't see how the numbers move forward and backward as they change—the ten digits in a nixie are stacked one above the other.

I want one! Unfortunately, because nixies haven't been produced in volume for a couple of decades, they are hard-to-find and expensive.

One can buy already-built nixie clocks (for a few hundred dollars), but any self-respecting geeks will build their own. Maybe if I get one of those cool jobs at Google, where you spend 20% of your time on personal projects, I'll give this a try.

I think the "Lost" production designers missed out when they didn't use nixies for the 108-minute countdown clock.

[UPDATE: I couldn't help myself. I ordered one of these.]

Wednesday, December 07, 2005


Congratulations to Other New Private Pilots

A couple of other student-pilot bloggers passed their Private Pilot checkrides at around the same time I did. I congratulate them:

We're all so cool, aren't we?


To Fix Or Not To Fix

Whenever I have to modify some code, I like to leave it better than I found it. In the wild, one finds a lot of "bad code." That's not because the people who wrote it were stupid or careless; we programmers just never have enough time to do things as well as we'd like. So there is always room for improvement, and I improve whenever I can. There are always poorly named variables and subroutines that can be renamed, expressions that can be simplified, methods that can be extracted, dead code to be removed, boundary conditions to be considered, and comments to be added (or updated or deleted).

However, some code is so screwed up that you can't improve it. It's so complicated that you can't tease it apart without fear that you will make it worse. Without automated tests, you can't verify that the "improved" version does exactly what the old version does. Without talking to the original programmmers (who left the company years ago), you can't figure out why they did it they way they did, so you don't know if there is some subtle problem that requires the strange implementation they chose.

I always feel guilty when I leave bad code as-is. I always think that the reason it is bad is because people like me are afraid to touch it. If somebody doesn't dive in and do the hard work, it will never get better. When I refuse to try to fix it, I'm part of the problem.

In such situations, I console myself with the rule that one should "first, do no harm." Maybe I'm not making it better, but at least I'm not making it worse. But that isn't much consolation. If I'm making changes around the bad code, without touching the bad code, I probably am making things worse. I'm just adding hacks on top of hacks. I'm just making the next programmer's job harder, because that programmer will not only have to figure out why I did what I did, but also figure out why I left the god-awful stuff around it alone.

An important step in the maturity of a programmer is the stage where the programmer is no longer afraid to change other peoples' code. Extreme Programming (XP) holds Courage as one of its core values. Discovering "this is bad, but I know how to make it better" is the one thing I enjoy about maintaining legacy code. Unfortunately, my courage often falters, usually because of an approaching deadline.

And when one does the right thing, and spends a couple of days turning an incomprehensible mess into beautiful, verifiably correct code, there is no appreciation. Management considers such activity to be a waste of time. Other programmers will nitpick, or make fun of you for being one of those design patterns cultists.

I'd like to have some simple rules to follow when conducting the triage of determining whether some bad code is best left as-is, or should be fixed, or should be thrown away. But this is one of those "hard problems" that comes with being a software engineer. You have to guess, and you will never know whether you were right.

Monday, December 05, 2005


Back to Work

For the past several months, I've been working part-time. This gave me a couple of days per week to take flying lessons and generally screw around. Next week, I go back to a full-time schedule. This is both good and bad.

The best part is that I'll go from making 60% of my full-time salary to 100% of my full-time salary. Another way to think about it is that I'm getting a 60% raise.

Going from four days off per week to two days off per week is obviously the bad part, but it's not all bad. Working part-time has been frustrating in many ways. It doesn't seem like I get anything done. I don't get invited to important meetings. I haven't been involved in any important projects. I've felt guilty going home for my long weekends when I know my co-workers are working 60-hour weeks. So, I hope that going back full-time will make me feel more productive and like part of the team again.

But I know I'll be complaining about full-time work in a few weeks. Life would be so much nicer without all these damned jobs.

Sunday, December 04, 2005


Why I Want to Be a Pilot

I found the following text on several web sites. It is usually attributed to an anonymous child (of various ages), but I suspect it was actually written by an adult as a joke. If anyone knows who the original author is, please let me know.

Why I Want to be a Pilot

I want to be a pilot when I grow up because it is fun and easy to do.

Pilots don't need much school, they just have to learn numbers so they can read instruments.

I think they should be able to read maps so they can find their way if they get lost.

Pilots should be brave so they won't get scared if it's foggy and they can't see or if wing or motor falls off they should stay calm so they'll know what to do.

Pilots have to have good eyes so they can see through clouds and they can't be afraid of lightning or thunder because they are closer to them than we are.

Pilots are always rich, they make more money than they can spend. This is because most people think airplane flying is dangerous except pilots don't because they know how easy it is.

There isn't much I don't like, except girls like pilots and all the stewardesses want to marry them and they always have to chase them away so they won't bother them.

I hope I don't get airsick because if I do I couldn't be a pilot and would have to go to work.

Saturday, December 03, 2005


Other Dreams

With the learn-to-fly-an-airplane dream met, I've been wondering what I should do next. Of course, there is always more to learn with the airplane, and I'm pretty sure I will go for an instrument rating and other advanced ratings, but I'd like to pursue some non-aviation-related dreams as well.

Unfortunately, life isn't long enough to do everything I'd like to do, so I need to prioritize. I'm brainstorming to figure out what other dreams I want to satisfy. Here's the list I have so far:

The surfing thing is foremost in my mind right now. Unfortunately, it's not the right time of the year to start. Maybe I should take a vacation in Australia.

This page is powered by Blogger. Isn't yours?