Most of my compatriots on the No Fluff, Just Stuff tour have blogged about the first symposium of the year, so I guess it's my turn.

I'm excited that things are rolling again. These are excellent events for the attendees, and also for the speakers. I'm always energized and enriched by spending a weekend talking to the other speakers and the audience members about software topics. (You'll notice that both the quantity and depth of my blogging has decreased during the break since the Atlanta symposium at the end of November. I expect it to begin picking up again now.)

This weekend in Austin I gave five talks. The two older talks (Introduction to XPath and Java Web Start and JNLP: The Return of the Rich Client) were both well received, and the three new ones went much better than I expected:

• Concurrent Programming Utilities -- I had a nice crowd for this one, and they were excited to learn about utility classes that can help them build better concurrent systems. More than one person said that they wished they had been to my talk a year ago, because it would have saved them a lot of grief.
• Introduction to Aspect-Oriented Programming and AspectJ -- I need to work on a better demo and a few more diagrams to help illustrate some tough concepts, but folks liked the talk anyway, and I don't think I lost anyone!
• Project Infrastructure Values, Principles, and Practices -- This is my favorite talk of the bunch, and it also went really well. It ended up being about 20 minutes too short, which was unfortunate for this time, but it's nice because it means I'll have time for some demos and more in-depth information next time around.

I'll be doing the same slate of talks at the Northern Virginia Software Symposium the last weekend in March. I can't wait!

Doin' the blog roundup today, two items really had me shaking my head in amazement.

First was the news (via LtU and lemonodor) that Yahoo! has finally succeeded in moving Yahoo! Stores (originally Viaweb) from its Common Lisp roots to a new, C++ implementation. But only sort of -- in Paul Graham's message about the switch, he reveals that the new implementation contains a new Lisp interpreter. (This is no surprise, really, since the store interface requires a runtime Lisp interpreter.)

In combination with that, what's really puzzling is this comment: "The reason they rewrote it was entirely that the current engineers didn't understand Lisp and were too afraid to learn it."

Just after reading about Yahoo! Stores, I read Bill Venners' account of some excellent and well known programmers discussing programmer interview tactics. There's a lot of good stuff in there, including this from Dave Thomas:

Hire for talent. [...] The world changes, so you need to hire folks who change with it. Look for people who know computing, not necessarily particular narrow niches. Not only will they adapt better in the future, they're also more likely to be innovative in the present.

and from Chris Sells:

To identify how good the candidates are technically, I let them choose an area in which they feel they have expertise. I need them to know something well, and I ask them about that. [...] I'm not necessarily after an expert in the area I need. If they learned why in the past, I have confidence they'll learn why in the future.

Now let's return to the original story about Yahoo! Stores. On LtU, Ehud Lamm quite reasonably wonders "whether maintaining a Lisp interpreter written in C++ is cheaper than sending new engineers to study Lisp."

I'd like to emphasize the phrase "new engineers" in that sentence. If you have engineers who are afraid to go learn Lisp in order to maintain an extremely successful existing application written in Lisp (but who paradoxically think it's fine to write their own Lisp implementation to support the customer base) then you need new engineers.

A lot of people don't understand the concept of "acquired tastes". I've heard people say things like, "If you have to work to learn to like it, why bother?" The answer, of course, is that acquired tastes are often some of the most pleasurable experiences around. Take, for example, Vegemite. (OK, that might not be your favorite example of an acquired taste. But you know what I mean.)

I got started thinking about acquired tastes this morning when I read what Darach Ennis had to say about test-first design/test-driven development (via Brian Marick):

Sometimes it's better just to roll up one's sleeves and give it a shot.

That's how I started out with TFD/TDD. One day I just decided to give it a shot. It took a few weeks before TFD/TDD clicked. It took another few months before I started to become proficient.

Food and drink aren't the only things that can only be enjoyed after a concerted effort. Habits of mind are just like habits of the palate -- our impulse is to continue to enjoy the comfortable and familiar, but growth happens when we challenge ourselves to try something different.

I can't stop giggling at this, from this month's edition of Bruce Shneier's Crypto-Gram:

An amusing, but irrelevant, incident: A week after the [Slammer] worm, I was invited to speak about it live on CNN. The program was eventually preempted by the Columbia tragedy, but not before the CNN producers invited Microsoft to appear on the segment with me. Microsoft's spokesman -- I don't know who -- said that the company was unwilling to appear on CNN with me. They were willing to appear before me, they were willing to appear after me, but they were not willing to appear with me. Seems that it is official Microsoft corporate policy not to be seen in public with Bruce Schneier.

James is taking his TiBook along on visits to his therapist now:

I remember reading project management literature in the early '90s, and really enjoying the works of Tom Gilb. The thing that sticks out the most in my mind is Gilb's Law:

Anything you need to quantify can be measured in some way that is superior to not measuring it at all.

Programmers are fond of saying "you can't really measure that," and Gilb's law says that's just a cop-out -- it might be hard to measure, and the measurements might not be 100% accurate, but anything is better than nothing!

It's hard to argue with that (and I don't really intend to). But like so many simple, absolute statements, it hides a lot of messy complexity. So much complexity that you (or your project) can fall into it and drown. There are three big traps lying behind Gilb's law.

1. Difficulty equates to cost. People have to work to get those measurements, the procedures may hurt productivity, etc. And if the measurements are of low quality, do they really offset the cost? Gilb's law says that measurement is possible, and it's always better than not measuring -- all else being equal. But the cost of the measurement may nullify its benefit.
2. Whether you call it Heisenberg's Uncertainty Principle or the Hawthorne Effect, the result is the same: measurement nearly always has secondary effects. And they may or may not be desirable. Are the people on your team optimizing for the measurement? Is that going to help or hurt your real goal?
3. Finally: few people deal well with ambiguous numbers. No matter how many times you say that the numbers have a margin of error, or may reflect many other factors, most people look at measurements and behave as if they're absolute.

Gilb's law is a law, but when it hits the complexities of the real world, the result can be messy. Use it carefully.

Today, NASA is thinking it probably wasn't a problem with the insulating tiles on Columbia -- or at least, not one that was caused by the main tank debris that hit the shuttle on liftoff.

Nevertheless, the most disturbing thing to me about the whole affair is learning that, even if they knew there was a serious problem with the tiles, there would be nothing they could do. In such a case, I suppose there's always the chance of a rescue mission by one of the other shuttles or by a Russian craft. But you can also think of dozens of reasons why such a thing wouldn't be able to happen in time. So NASA says they didn't even do an EVA to check the tiles, presumably on the assumption that it would be better not to know. It's hard to argue with that, assuming that they really couldn't do anything about it.

I don't guess I'm really surprised by this. Working in vacuum and microgravity is difficult, and putting those tiles on is notoriously tricky under the best circumstances. I know they use a special adhesive, and who knows whether that would adhere or dry properly in vacuum, or in the cold? And maybe they have to be applied under high pressure. But even though I'm not surprised, it's very troubling to think about that situation: there's something badly wrong, and it seems trivial (missing tiles!), but the crew will die, and there's nothing they or anyone else can do.

It points to the next big challenges of spaceflight. Somehow we have to have a cheaper, simpler way out of the gravity well, so that we can have ships that are simple enough to be repaired in space. And we need to work on technologies that make it easier to work in microgravity and vacuum: lighter, less constricting and more flexible spacesuits, as well as thrusters or other tools that make it easier to get around, and ways to gain leverage in the absence of weight and friction.

(Oh, and I'll second what Rael said.)