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:
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 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.
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.
Woman bags three deer in week; family will have plenty of venison.
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.
This morning I was copying something to my iDisk, and it bogged down. I had to get to work, so I tried clicking Cancel, but the Finder was unresponsive. I finally had to just unplug and go.
When I got to work and opened the machine again, things were still stuck. I tried a restart, but 10 minutes into the shutdown process, looking at a machine that wasn't doing anything, I powered off. The fsck on reboot found a lot of things to fix. I hope all my data is OK, but in any case, it's time for the safeguard of the journalling filesystem.
I've been amazed at how well Google's news service works. But no matter how good the technology is, occasional mistakes are inevitable when computer programs try to compile and correlate news headlines from lots of different sources. Today, some of the seams really showed.
In the "Top Stories" section at the top of the page, there's always a subsection called "In the News" that contains a short list of topical links: topics that seem to be getting a lot of coverage, but haven't made it to the prestige positions that include headlines and pictures. The links in "In the News" aren't headlines. Instead, they're topic keywords that have been extracted from the headlines by the Google software. Things like "Tel Aviv," "Harry Potter," and "NATO Summit."
Today I noticed three topics in particular: "Our Man Flint," "Magnificent Seven," and "Academy Award." It's clear what's going on there -- news outlets are writing about the death of James Coburn, and Google is picking up on references to his achievements and most famous films in the headlines. But when I clicked on the topics, things got even more interesting.
The page for Our Man Flint was 10-for-10. All the stories were about Coburn. Academy Award was somewhat mixed, since there are other Oscar winners in the news this week.
But I was really surprised when I clicked the link for Magnificent Seven. Just looking at the first ten hits, I learned:
I don't mean to take anything away from what Google has achieved. All things considered, it works amazingly well. And quite frankly, occasional strange juxtapositions like this can be good -- they add an element of the serendipity that's present in a real newspaper, where you can occasionally run across a fascinating article that you never would have looked for.
Think about it. I'll probably watch at least one of those Coburn movies on TCM Sunday night. The story about the horses was interesting, and I was surprised to learn that five years have gone by since the McCaughey septuplets were born. And it's interesting that the producer of the film and one of its stars died during the same week.
I learned one more thing, too. All of those stories included the words "Magnificent Seven" -- most of them in the headline. The name of the film has entered our language. That, in itself, says something about the legacies of James Coburn and Marvin Mirisch.
Patrick's suggestion (which I can't believe I didn't think of myself) is to teach them more about the history of our field. We don't have to make computer science students scholars of computer history, but we should give them some idea of the rich scope of the topic. Introductory computer courses tend to cover Babbage, Turing, and von Neumann, and then skip straight to Bill Gates. And for most CS students, that's the end of it.
Michael's suggestion is this:
... professors often understand the distinction between teaching skills for their own sake and teaching them as applications of more general principles. It's important to convey that to the students as well. Giving an idea of trends and perspective helps breed the kind of healthy skepticism about tools and paradigms that Glenn mentions.That's absolutely right. All too frequently I meet young programmers who are confused about that -- they think the particular techniques and tools they were taught are the fundamental things.
Here are the other things I've thought of: