Brian Marick writes wonderfully (as usual) about how requirements documents and tests communicate the same thing in different ways. The interesting point is that, although it’s difficult to see how tests communicate the necessary information, for various reasons they do so more effectively than a requirements document. It shouldn’t be surprising that we have a hard time convincing some people of that.

I’ve been thinking about a related issue for a couple of years now. In The Mythical Man-Month, Fred Brooks writes about “the project notebook”: the authoritative source for information about the project. And it sounds like such a good idea. It’s easy to see how that would work. It records important information precisely and directly.

It’s also—as you begin to understand when you read Brook’s ideas for how to manage the project notebook—incredibly unwieldy and inefficient. And while the notebook might (if you spend a lot of time and money on it) contain all of the important information, it’s highly unlikely that it would ever be completely understood, by the right people at the right times in the right ways.

It works much better to let the code—the system itself, plus executable tests—serve as the project notebook. This is why iterative development is so important. The code is functional, and it gives us feedback about our understanding. (More importantly, it gives us feedback about our misunderstanding.) If we think we know something about how the system works, we try to write code that depends on that knowledge, and the system will tell us if we were correct. With the project notebook, on the other hand, we might not learn about our error until weeks or months have passed, by which time the ripple effects from our mistaken assumption will be tremendous.

Another common objection to agile styles of development goes something like this: “You mean you don’t document or model design decisions that come out of a meeting? Haven’t you ever been to a meeting where everyone thought they had reached an agreement, only to find out that each person understood the decisions differently?” Sure I have. But the problem there, I believe, is largely that people have a hard time communicating about abstract things. Handwaving, and even boxes and lines, aren’t really very expressive about what software is. I’ve been in a lot of those discussions, and the problem is that there’s almost no feedback about whether you really understand what’s being said. I’ve been completely confused and at the same time absolutely convinced that I understood everything.

When people have those same discussions in the context of code—working code—communication changes. It may seem strange to say this about software, but code is concrete. It’s unambiguous. It grounds our discussions in a reality, and it’s a terrific aid to effective communication and understanding. It provides a feedback mechanism for the act of communication. If you don’t understand what’s being said, then the proposal (more often than not) won’t make any sense when held up against the code.

It’s no wonder that, in many test-first teams, design debates are frequently carried out through unit tests. The “conduit” and “program” metaphors of communication each have their strengths, and the best policy is to let them support and reinforce each other.

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.