I have a strong preference for simplicity in software, and I’m frequently frustrated by people who seem to value complexity instead, and who don’t seem to understand why the simpler solution is usually preferable.

But I shouldn’t be so hard on them, I guess, because it’s all a matter of degree. There are designs that are too simple for me to really grasp. And I don’t mean designs that are too simple to work; I mean designs that seem too simple to me, because I don’t understand how the simple solution meets all the needs. Want examples? Take a look at nearly everything Ward Cunningham does.

FIT is the latest thing Ward has blown my mind with, but it’s certainly not the first:

• I’m sorry, but how could the WikiWikiWeb ever work? This simple little web site, with a trivial formatting language, where you create new pages just by linking to them, and you link just by SmashingWordsTogether, and anyone can edit the entire text of any page at any time. But it does work, and it created a vibrant community of mostly like-minded software developers. It makes a terrific discussion tool for teams of almost any size.
• Last year at OOPSLA, Ward helped run the workshop on Software Archaeology. His position paper floored me. He presented perhaps the most useful tool discussed in the workshop, and it’s one that he wrote himself in less than a hundred lines of Perl.
• Also last year, after Bob Martin and Robert Koss used the development of a bowling score program to illustrate the process of pair programming, several people in the XP community used the same example to illustrate other parts of the process, and different programming techniques. Ward’s solution was unique in its approach, and the only thing that makes it at all difficult to comprehend is that it’s written in a rather unnatural style of Perl. (Ward used Perl’s regular expression operations to simulate an APL-ish style of problem solving.) Once you get past that, it’s breathtakingly simple.

I’m embarrassed to say that I would never have tried any of those approaches to those problems, because they would’ve struck me as naive. But I would’ve been wrong.

The funny thing is that, as folks have mentioned FIT to me over the past few weeks, all of them have said something like this: “It’s a little mind-bending, but knowing Ward, I suspect the problem is with my mind, not FIT.” That’s exactly how I feel. It’s good to know I’m not alone in that.

It’s been a while since I subscribed to the XP mailing list, but I manage to hear about most of the important developments, I think. A few weeks ago, Dave Thomas told me about FIT, Ward Cunningham’s Framework for Integration Testing.

It sounded intriguing, but I really didn’t have time to investigate it. Then, at the Lone Star Software Symposium in early November, Daniel Steinberg mentioned FIT and how interesting it is. And last week, Mike Clark sent me a draft of some early work he’s done with FIT. By the rule of three, then, I suddenly had to spend the time on it … when three people of that caliber are talking about something, it deserves attention.

And FIT does deserve attention. Ward designed it to address one of the more difficult parts of Extreme Programming: the idea that customers should specify—and ideally write—automated acceptance tests. FIT is a fascinating approach to that problem. Naturally, the programmers must help, but they help in very small ways; primarily by writing tiny, simple adapter classes that hook application objects into FIT.

FIT is still in the early stages, and there are numerous problems to be solved. But it has the potential to work really well, at least partly because it is simple and adaptable rather than feature-complete and all-encompassing. If you haven’t looked at it and played with it, make the time to do so.

I spent part of lunch today in the bookstore. Cryptonomicon is finally out in a mass-market paperback (approximately a foot thick). And I couldn’t help but notice that the cover said it contained an excerpt from Quicksilver. Next thing I knew, I was in one of the big comfy chairs.

The excerpt definitely made me want to read more. (I’ve been getting hungry for more from Stephenson anyway.) It takes place around the turn of the 19th century, on the cusp of the Enlightenment. We see the ancestors of Lawrence Waterhouse and Bobby Shaftoe, along with Isaac Newton, Liebniz, a young Ben Franklin, the founding of MIT, and—as many have suspected— Enoch Root.

It’s the first volume of a series called The Baroque Cycle, and apparently it will be published in October, 2003.

I wrote yesterday about the occasional seams that are visible in Google News. Today, just for fun, I went back to the Magnificent Seven page to see if any more strange stories had shown up on the first page. Sure enough, from the Detroit Free Press:

Woman bags three deer in week; family will have plenty of venison.

(via my O’Reilly blog)

There’s a new security hole in Microsoft software. An ActiveX control, supplied and signed by Microsoft, can run arbitrary programs on your computer. Microsoft has issued a fixed control, but there’s still a problem: sites can request the vulnerable version, and it will be fetched and reinstalled.

Microsoft’s solution: remove Microsoft from your list of trusted providers (if you ever put them there, that is).

It’s tempting just to chortle at this, but it illustrates serious problems with the code-signing approach in general. Way back in January 1997 I wrote that the ActiveX security architecture wasn’t actually a security architecture; at best it’s a blame-assignment architecture. I believe that even more today.

I’ve worked on projects that do code signing. And there are big security holes in the whole process. Think about how organizations work. Too many people will have access to the signing key. Signing becomes part of the automated build process, and it stays there even if security audits fall by the wayside. (Assuming, of course, that there ever were security audits.) You have to be careful with trusting individuals. Why would you ever grant blanket trust to a corporate entity?

Ken Thompson was right. The problem of trust runs deeper than technology.