I've been off the air for a bit for purely mechanical reasons: it seems that the IBM developerWorks blogs have been rehosted to a new hardware platform, and the mechanism we'd put in place to mirror my blog from here to the IBM site was broken. The good news is that the bean on the IBM end has been fixed, but the bad news is that there remain some firewall issues on the IBM hosting side that require meetings and memos; in short, it's no longer a technical problem, but a process problem. I'd been waiting to post here until the mirrroring mechanism was fixed, but since it looks like it will take some time, I've decided not to wait, for I have a number of things in the queue to talk about (and in the meantime, we'll probably toss a human in the process to manually repost from the Handbook to the IBM site).
Where to begin? Well, over the weekend, I crushed and melted my remaing PC, and so now my life is pretty much running on a Powerbook (with a few bits sprinkled across the other Macintosh and Linux boxes, of course). I have about 99% of everything I need on this machine: I can VPN, Eclipse has been solid on this platform for some time, Lotus Notes works wonderfully, I've moved over to AdiumX to fuse all of my instant messaging needs, and with having the moral equivalent of Unix under the hood, there's a wealth of developer toys at my disposal. Oh, and I have so much more free time on my hands now that I no longer have to deal with the daily whining and surprising/aberrrant/mystical behavior of a high maintenance Windows XP installation.
Another random thought that needs to be aired: as I continue to unearth the handbook's architectures, and in the context of a couple of recent customer architectural engagements, it's clear that there is a curious relationship between the angst a team vocalizes regarding their difficulty in instituting a reasonable configuration management (CM) practice and the underlying architecture of that system. In short, some of that angst is offten legitimately an issue with the CM tools themselves (performance, usually), but my take is that most of that angst is really a manifestation of the project having a poorly architected system in the first place. If you don't have an architecture with a clear separation of concerns among components, then it's really quite difficult to impose a meaningfuly CM strategy upon it at all.
Yet another random observation: in the September 13th issue of Infoworld, Tom Yager discusses the future of Intel's Itanium, noting that for Intel to succeed, "Intel has to build compilers that generate deadly code for operating systems designed for serial execution." In other words, Intel's ability to develop killer software is a key competitive advantage for what is essentially a hardware company. A couple of years ago, I was at an event with Gordon Moore and I began my remarks, knowing that Gordon would be talking next, by saying that while I certainly respect his work and the work of Intel, they would have nothing but a pile of pretty sand were it not for the software that ran on their chips. Gordon, not surprisingly, began his remarks by saying that my software would be lifeless without his hardware. I suppose this is the yin and yang of our industry: software without hardware would be like, well, a fish without a bicycle or a hunting trip without an accordian.
Last item in the backlog: in a number of my public presentations, I've talked about the limits of software, the factors that separate our vision from execution. Well, I finally got around to writing up that particular riff in a short paper, which you'll find here.