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