IMO

I'm sometimes asked why I left NASA, especially after having spent so many years there and after having a career that really moved (by the time I left, I had been a GS14 for several years... a *technical* GS14). Having grown up in the 60's, I was one of those kids who watched and followed the space program in fascination. Wow, if I could only work for NASA! That was a dream. When I graduated from Johns Hopkins, NASA was actually hiring, after a long dry spell. I inteviewed and, before you know it, I was working for NASA Goddard, designing and modeling power systems for unmanned satellites. It was a heady time; there were a bunch of us 20-somethings working on real-life spacecrafts, occasionally needing to get in those monkey suits in the clean room to work on or fix some flight hardware. Engineers were respected and listened to. And then it all changed... Bean-counting became much more important; managers were the people with the respect (and engineers just got in their way); "cheaper-better-faster" was a mantra, as if we were flipping burgers rather that creating high-quality space hardware and software systems; work became secondary to appearances and "providing value." NASA became, well, corporate. And in addition to being low men on the totem pole, engineers saw all the fun, interesting work sub-contracted out, and we simply got to "oversee" what those contractors were doing. The final straw came during a non-unique situation where, in an attempt to save some money (an extremely small fraction of the total cost of the spacecraft), the contractor decided that they could use smaller capacity batteries than what I thought. These were smaller and lighter and cheaper, and so there would be benefits all around. This is all well and good, but only if the batteries actually *lasted* as long as they were supposed to. You see, during the spacecraft orbit, it goes into shadow behind the Earth, and at this point the batteries take over and provide electricity. Batteries have capacity measured in ampere-hours (AHrs) and as they discharge you measure how much capacity they take out (this is called the "depth of discharge" or DoD). Anyway, it makes sense that if the capacity is smaller, then if you need to take the same amount out of a 25AHr battery and a 50AHr one, the former will have a higher depth of discharge. The problem is that battery life depends on DoD. By them using the smaller batteries, they would never reach the 3 year life goal, and this was my complaint. My supervisor and I complained to our branch head, to our division head, up to our directorate head, at which point we were slammed down. He didn't agree, the contractor and project were right, and we were wrong, and we should stop complaining. To heck with it, we thought, we'll *prove* it; we designed some battery stress tests, ran them and, sure enough, the data showed that there was no way on God's Green Earth those batteries would survive 3 years. With this data, the contractor and project were forced to change the batteries. By this time, the structural and mechanical design had already been done, so there was a lot of work involved in changing things for the new design (which rippled, since the guidance system also needed tweaks to adjust for the different mass and inertial loading on the spacecraft) and the project's budget and schedule got hit. And then my supervisor and I were called into our directorate chief's office. We both expected some sort of congratulations about finding a problem and working beyond-the-call-of-duty to make people aware of it. But nope. Instead, we were chastised for not making a big enough stink about it earlier on. "But we brought the matter all the way up to you and you told us to stop, that the decision was made," we said. "Doesn't matter," he replied. And then he said something that I'll never forget, and this is the honest-to-God's truth: "You both should have made up signs and protested in front of the Administration building (where the Director of Goddard's office is) until *he* did something." At that point it was obvious that protecting one's job and not making waves were the primary focus on upper management. If we could save money *now*, even if it meant that we didn't reach our design goals, well, that was a risk they were willing to take. Because if you made noise, you were passed over. And as time went on, that trickled downstream to even branch heads. Rubber stamping became the norm, because no one wanted to be pegged a "trouble maker" or "not a team player." And so the fun was gone... I found myself getting much more fullfillment from the stuff I was doing with and on the Internet and so decided to move on. I've never regretted it. And it sounds like NASA is still suffering from those problems that made me leave... I'll tell you one thing NASA can do to help things, and it's a lesson from Open Source. Focus on creating a *community*; a healthy, active, collaborative community. You'd be surprised at the change.

There has been a lot of discussion and effort recently in getting Apache HTTP Server v2.2 ("Apache 2.2") ready for prime time. The HTTP Server project is using the even-number=stable|odd-number=development naming strategy [Note: this doesn't apply to the 1.3 tree], so we are actually working on Apache 2.1 (and 2.3) which would then become Apache 2.2 (and 2.4). The destined-to-become-2.2 branch was just created a few months ago (to my surpise I must say: it happened while I was away on vacation and offline and so didn't realize that trunk was no longer the direct 2.2 path!). One discussion was regarding whether it was more efficient or more problematic to basically have 2 paths that, at least for now, so closely track each other (so that a commit to one also needs to be (re)committed to the other). So far, now that everyone is clear on the procedure, things appear to be moving well, but the 2.3 and 2.1 paths are still basically the exact same. The other discussion has been whether the 2.2 releases should contain the 'experimental' module directory... this is still ongoing, and could likely be resolved just by a name change. The idea is that there are modules that we bundle that haven't experience the world-wide testing that others have, and so marking them as experimental (as we do now), allows for people to try them out, and hopefully provide feedback and fixes. The counterpoint is that providing modules that are classified as "experimental" is a disservice to the community... I take the former position. The big question, of course, is whether 2.2 will provide enough reason and rationale for people to upgrade from 1.3 (and 2.0 as well)... the new feature list is impressive and addresses some known and "complained about" deficiencies in 2.0, so the odds are pretty good. Personally, it will be nice to see 2.2 out the door and in use. Developers like developing code that people use, and with the (wise) restrictions on changing too much in 2.0, the 2.1/2.2 tree has been the fun place to work. But after awhile, you want it to be actually *used*. We're getting closer and closer to that happening...

Talk about your 180's. RoR has really gotten me into the joy of Ruby, even without using Rails. It's hard to get used to the "everything is an object" idea, because we're so used to all the caveats other languages have. But once you learn to trust Ruby, things just flow. And Mixins just make it all better. For example, on some apps, I needed to be able to skip selections within an Array ("grab every 3 elements"). The below little hack makes that super easy to implement, and use those methods naturally and natively.

class Array   def each_x(x)     (0 .. (length.to_f/x).ceil - 1).collect { |i| yield(self[i*x]) }   end   def every(x)     each_x(x) { |i| i }   end   def collect_x(x)     each_x(x) { |i| yield(i) }   end end

I have a nasty little secret: I still do a lot of coding using vi (well, actually vim). When I need or want something more "robust" then I'll use BBEdit. If I need something even better, then I'll use Xcode (see a pattern there?). I do find myself selecting Xcode more and more, BBEdit a bit more, and vim a bit less as time goes on. Mostly, of course, it's due to the wide-ranging complexity of multi-file projects and applications, and the old methods just don't scale anymore. I hardly ever use Eclipse: Xcode is much nicer, IMO, but I expect to find myself eventually moving more to it, simply for the cross-platform aspects. And I've never used emacs. There. I said it.

I haven't posted anything about Katrina... there seems to be such a huge amount of copy (both real and virtual) about it, that adding more seems almost wasteful. Obviously, though, if you haven't donated to help the effort, please do so; the human tragedy is heart-breaking. I have opinions regarding how the whole disaster was handled, and, as with most people, I think it was obvious that we were not at our best. A lot of people and essential services let down whole communities; it's embarrassing. And I feel kind of awkward even stating that, because how does embarrassment compare to losing everything, and being ignored? My "embarrassment" pales in comparison. One thing that bothers me a lot is how during these crises, you see people crawl out of the woodwork, to get a special photo-op, to get their names in the papers, to be talked about. Those "people" who uses these kinds of tragic events for political or personal gain sicken me. The real "story" behind Katrina are those directly affected; not those who contort the story around themselves.