Thursday, December 23, 2004, posted by @ 8:54 AM
Collaboration
I typically ignore the Microsoft marketing machine: while occasionally entertaining, the messages therein are typically so void of detail, suspect of schedule, and full of noisy FUD that they are distracting. Recently, however, a colleague forwarded me a link to a presentation about Visual Studio 2005 Team System that I couldn't ignore, because of its use of phrases I remember writing several years ago.
I do respect Microsoft's work in this space: development is a team sport, and tooling for most domains requires far more than just a faster/better/cheaper compiler and debugger. In the VSTS Tech Ed 2004 presentation cited, Rick LePlante and crew presented Team Studio. What first struck me is his use of the phrase "friction free" development. About four years ago, Alan Brown and I wrote a paper on collaborative development environments (since published in Advances in Computers, volume 59 and also mentioned in my EclipseCon keynote provided in the references section of the blog). Rick is correct - though he's a few years late in recognizing it - in that integrated development tools are all about reducing the friction among different stakeholders. Speaking of stakeholders, the Microsoft presentation here is also virtually the same as IBM Rational has described for several years with regard to our suites, and their mention of having a rich partner ecosystem is what Eclipse is all about, although the former is captive and proprietary while the latter is open.
Following the demo in Rick's presentation was interesting, but IMHO a bit naive: on the one hand, Team Studio does automate some of the mechanics of change control (that's a good thing) but it totally ignores the things that can be done to address the social dynamics of collaboration (that's a bad thing). Some of the things Team Studio automates simply adds some ceremony to what you'd get in a development team that was already jelled and embodied good communication patterns, but the scenarios covered by Team Studio didn't necessarily encourage those good practices in teams that were geographically and/or temporally distributed or already somewhat dysfunctional. Messaging, presence, the formation of small, temporary work groups, lightweight artifact workproduct version in, the existence of a virtual team meeting space: these are collectively critical to addressing those social dynamics, and that's the trajectory that I see such tooling needing to go (also as I explained in the EclipseCon keynote).
Wednesday, December 15, 2004, posted by @ 11:42 AM
Architecture Of The World Wide Web
The W3C issued a fascinating report today on the architecture of the World Wide Web. Tis very interesting reading; I especially enjoyed section 5 on general architectural principals.
Wednesday, December 8, 2004, posted by @ 5:44 AM
Links
I've been slogging through a 3 foot high pile of clippings and articles I've collected the past several months, all randomly encountered factoids on various of the systems under study for the Handbook.
Politicians have think tanks, but check out Vanguard, one such group for our industry.
On a completely unrelated topic (I told you these were randomly encountered; this is sort of a meta-archeological dig I'm conducting), while most of you reading this are likely engaged in enterprise systems, there's a whole world out there beyond servers and such, as for example in the area of medical electronics. I've met some teams who build such devices (thank you!) and recently encountered a computed tomography system from Siemens. The physics for these devices are well-understood, and while there continue to be hardware advances in terms of resolution and performance, the biggest focus in this space is the operational software; labs typically buy a machine (a million or so a pop) but then enter into a stream of software upgrades over the years, adding various features and improving visualization. I honestly know nothing about the software architecture of such devices - which is why it's in my list for the Handbook (I write books in order to learn, and there's soooo much that I don't know).
Friday, December 3, 2004, posted by @ 10:47 PM
Microsoft And Domain Specific Languages
The past couple of months, Microsoft has unleashed a torrent of words detailing their marketecture for software factories. Alan Brown and Simon Johnston of IBM Rational have previously and very ably commented on this work, but Steve Cook of Microsoft has drawn me into the fray in his blog, so I feel compelled to reply: Steve wrote "I hope Grady Booch reads this"; well, I did :-).
I know many of the folks involved in Microsoft's software factory effort, and I very much respect what they are trying to do. We have differences of opinion, as you'll see in this blog, but it's good to watch Microsoft putting some energy into improving the development experience. As I've said many times here and elsewhere, software development has been, is, and will remain fundamentally hard, and whatever can be done to improve the profession of developing software is a Good Thing.
That being said, I'm disappointed that Microsoft choose the term "software factory," because it's an emotionally-laden phrase that harkens to extremely mature manufacturing methods that focus on stamping out endless copies of the same thing, although perhaps with slight variants therein. There's no doubt that reuse at the level of design patterns or, even better, vertically-oriented architectural patterns is a Good Thing, but what Microsoft is proposing to do is not exactly like the manufacturing metaphor, and so their use of the term is a bit misleading (although Steve has curiously used the image of a conveyor belt when describing the Microsoft factory process). Tom Demarco in his book Why Does Software Cost So Much? sets aside a chapter on software factories in which he notes - and I agree with him - that "I think factory methods for software are dead wrong, witless, and counter-effective. Organizations that build good software know that software is an R and D activity, not a production activity. Organizations that try to make it into a production activity produce bad software (though potentially lots of it)."
At OOPSLA, Rick Rishad of Microsoft publically spoke of their strategy (in a somewhat controversial way, as reported by Spencer F. Katt, which was a bit surprising given the typically-frictionless Microsoft marketing machine). That strategy was subsequently reviewed in ADT Magazine. While I agree with much of that article, they too fell into the pit of taking the software factory term a bit too literally. Perhaps the best source of Microsoft's deep thinking in this space, in addition to their site, is the book by Jack Greenfield and others, titled Software Factories: Assembling Applications with Patterns, Models, and Tools. Therein you'll see Microsoft's emphasis upon reusable assets and tooling to support them.
To that end, there's considerable common ground between IBM and Microsoft's approaches to the problem: we both agree that reusable components, as manifest both in code as well as in patterns, are the right next stage in cutting the Gordian knot of software. Indeed, IBM's been in the pattern space for sometime, starting with many of the authors of the seminal book Design Patterns to the current work led by Grant Larsen and as manifest in the open standard we pioneered through the Object Management Group, the Reusable Asset Specification.
However, we do disagree with Microsoft's rejection of the UML in favor of proprietary domain-specific languages, as noted not only in Jack's book but also in Alan Will's blog. To be clear, as Jim Rumbaugh has commented back to me, our observation - and that of our customers - is that the UML has proven itself useful much of the time, yet there are a few purposes for which it may be less appropriate. In many cases, the semantics of the UML are pretty close to what you need, although they are deeper than necessary; in such cases, a suitable UML profile is sufficient to focus the language, which allows you to leverage standard UML tools and training and yet eliminate the bloat. In those cases where the business concepts are more naturally expressed in a specialized syntax, then inventing a suitable DSL is reasonable. At the extreme, this is essentially the path that Charles Simonyi has been treading for some years, a path that requires a very very deep and integrated underlying semantic model. Indeed, as I've pointed out in one of my earlier blogs, the root problem is not simply making one set of stakeholders more expressive, but rather weaving their work into that of all the other stakeholders. This requires common semantics for common tooling and training, so even if you start with a set of pure DSLs, you'll most often end up covering the same semantic ground as the UML.
Will's blog had a number of errors of fact, which Bran Selic has pointed out to me and so which I'll paraphrase here. Alan wrote "So here's why we don't want to limit ourselves to the UML as a basis for our users' domain-specific language" and then went on to say:
"A careful look at the specialization mechanisms for UML reveals their limitations. Stereotypes and tagged values allow you to change icons etc, although even simple alterations like decorating a box to show the state of some property isn't within range. You can't change the semantic constraints, or invent new sorts of diagram or new categories of element." This is incorrect: a stereotype allows you to define a set of associated constraints (in OCL, for example) that can capture the characteristics of your domain-specific context. While it is true that you cannot violate the semantics of the metaclass that you have stereotyped, this is actually an advantage of the stereotyping mechanism. A stereotype is a type-compatible specialization of an existing UML concept. Consequently, you can reuse standard UML tools and expertise even though you are using a domain-specific language. Of course, if you want a language that is incompatible with UML, that is OK as well (specifically, you can define it using MOF), but you will be losing some of those benefits.
"You can't take stuff away, so your users are always distracted by other options and elements and diagrams that aren't relevant to your language." Tools that use a UML editor as a front-end have to have a (very annoying) validation step before they generate their DB schema or whatever it is. " Also incorrect: as Jim noted above, a UML profile can remove any metaclasses it chooses.
"UML only includes certain types of graphical format. If you want your language to include tree-structured diagrams, or tables, or math formulae, or block-structured text, or prose, or if you want hyperlinks - well, I think you'd have a hard time. While our initial offering won't include all those styles, we'd certainly like to support them at some stage in the future." Actually, the current UML spec really does not restrict graphical formats in any way -- it simply provides a standard set of notations, but not at the exclusion of other notations. In other words, there really is no "illegal" UML graphical syntax. The formal definition of a UML graphical syntax is an outstanding item before the OMG. While this is not good, it also means that Alan's criticisms about its graphical restrictions are misguided - and Microsoft too acknowledges that these different graphical representations are a future desire for them, not a present reality.
"An important aspect of the definition of a modern language includes how you interact with it: how you navigate and elide or elaborate and edit etc - think of your favorite GUI composing tool, in which the GUI-defining language is scarcely separable from its editor. You can't do anything about these aspects in UML." We agree - but this has nothing to do with the UML but rather is all about the tool environment. IBM's tooling approach is to build upon the open standard of Eclipse, not a proprietary IDE.
"What you get out the back of one of our tools says things like CheckinDesk and ConveyorBelt. What you get out the back of a UML tool says things like Class and Stereotype - much more difficult to read. (Yes, of course you could write translators, but it's an extra layer of hassle.)" This is also incorrect: using the UML, at the model level you get back stereotypes called CheckinDesk and ConveyorBelt. At any rate, why would anyone want to look at things at the XMI or metamodel level? XML is not really for human consumption, and ultimately, MDD is all about raising the level of abstraction for the developer.
"You have to understand all of UML (stereotypes etc) before you can create your language on top of it." Not true: you just need to know the subset that you are specializing (mostly it has to do with things such as classes and associations which is what most profiles specialize). Of course, if you want to specialize state machines, you need to know the metamodel. But, if you don't care about state machines, you can ignore them safely.
"Your users have to understand an editor that's intended for something far more complex than they probably have in hand - or at least whose complexities are in a different direction." Again, this is a issue that confuses tooling with language definition.
I hope that Steve and Alan read this :-)
Monday, November 29, 2004, posted by @ 8:22 PM
Inventing The Future
I'm back from holiday but am now 12 hours from wheels up again to the east coast. I have some thoughts regarding Microsoft's software factory initiative which I've not had time to post, but will do so before the end of the week.
Speaking of holiday, our family took a cruise, and while a Fun Time Was Had By All, I was most taken by the degree of automation onboard. Docking the boat appeared to be an almost hands-free operation and the stability system -even under moderate seas - were quite amazing in keeping the vessel upright (which I suppose is always an important use case). Doing a dig of a ship's operational system is on my list for the Handbook although I've not yet started to identify which one to study.
I've been in the midst of planning Rational's projects with IBM Research for the coming year. We invested several million for Rational alone this year and will do the same for next year in the areas of model-driven development, quality, change management, middleware tools, and collaboration. A few of these plays are, quite frankly, long shots, but you need to do a few of them to seed and nurture the future. Some of these efforts will bear fruit in terms of yielding tangible products, while some will not, but even from these we'll learn a great deal. The depth of talent inside IBM Research is really quite amazing, and it's quite invigorating to work with these folks who are scattered in labs across the world.
Tuesday, November 16, 2004, posted by @ 6:39 AM
For Whom the Bell Tolls
I've told this story from time to time in my public lectures and I've decided to retire this tale, but before I do, I'll preserve it for reference in my blog.
My wife and I designed and built a home a few years ago, and being an alpha geek I just had to fill it with all sorts of automated elements. I hired a contractor to pull the wires (he put about 5 miles of Cat 5 wires in the walls) but as CTO/CIO of the home, I installed the rest of the network. Shortly after I booted the house for the first time, we invited some friends over for dinner. They arrived at the appointed time, rang the doorbell - but we never heard it. They knocked on the door - and we didn't hear that either - so they finally called us on their cell phone, while standing at the front door.
My doorbell had crashed.
Now, doorbells have very simple use cases: you push the button, it rings a tone inside the home. However, my implementation of said doorbell was a bit more complex, and I failed my user base by having the bones of the underlying technology stick through. You see, the doorbell sends a signal to our PBX system, which I hacked to extract events (such as the doorbell being pressed). That event gets routed to an application server - running a non-Macintosh, non-Linux operating system, I might add - which has a daemon that intercepts various events (such as from the PBX, the security system, and so on) and in this case would send an event to the A/V subsystem, where a seasonally-appropriate and pleasant tone would sound through the home. Alas, I failed to use Rational's own tools (Purify in this case) and I had a memory leak in my application server. The solution was to reboot that server, which brought the doorbell back to life.
I have a very demanding customer (my wife) who really doesn't like to have my software lying around on the floor, and so she was at first annoyed and then amused at the incident. The good news is that I've ripped out the first implementation (I'm not saddled by legacy software here) and my doorbell now works as any good little doorbell should, with all the complexity hidden below the surface.
Yet another example of why the primary task of the software development team is to engineer the illusion of simplicity.
Monday, November 15, 2004, posted by @ 6:17 AM
Service-Oriented Architectures
I've back from travel again, this time from trips to New York City and Chicago where I've been working with a number of clients on their emerging enterprise architectures. The common theme I've encountered is that large enterprises are beginning to see their way out of the global economic slump and so are turning their attention to what they can do to extract value from their legacy systems by unifying the artifacts and activities that reside across existing silos and by unifying their customer experience.
Speaking of legacy systems, one gentleman introduced me to the new phrase heritage software as a euphemism for old, tired software. A noble concept, but a rose by any other name is still a rose. It reminds me of phrases such as pre-owned vehicle and arbitrary termination of life.
Service-oriented architectures (SOA) are on the mind of all such enterprises - and rightly so - for services do offer a mechanism for transcending the multiplatform, multilingual, multisemantic underpinnings of most enterprises, which typically have grown organically and opportunistically over the years. That being said, I need to voice the dark side of SOA, the same things I've told these and other customers. First, services are just a mechanism, a specific mechanism for allowing communication across standard Web protocols. As such, the best service-oriented architectures seem to come from good component-oriented architectures, meaning that the mere imposition of services does not an architecture make. Second, services are a useful but insufficient mechanism for interconnection among systems of systems. It's a gross simplification, but services are most applicable to large grained/low frequency interactions, and one typically needs other mechanisms for fine-grained/high frequency flows. It's also the case that many legacy - sorry, heritage - systems are not already Web-centric, and thus using a services mechanism which assumes Web-centric transport introduces an impedance mismatch. Third, simply defining services is only one part of establishing a unified architecture: one also needs shared semantics of messages and behavioral patterns for common synchronous and asynchronous messaging across services.
In short, SOA is just one part of establishing an enterprise architecture, and those organizations who think that imposing an SOA alone will bring order out of chaos are sadly misguided. As I've said many times before and will say again, solid software engineering practices never go out of style (crisp abstractions, clear separation of concerns, balanced distribution of responsibilities) and while SOA supports such practices, SOA is not a sufficient architectural practice.
One more thing before I go. If I were a betting man, I imagine my ability to predict the future success of many of these organizations would be quite high (and I don't mean their technical success, I mean the very life of the company itself). There are some organizations I encounter in which there's a tight connection between the CEO and CTO/CIO (and development teams) - these are the companies I expect will flourish, for at the highest levels of the company they understand the strategic weapon that lives in software, and the importance in building a development organization that's able to execute predictably and with agility. Sadly, there are too many organizations where the highest level of the company simply goes not grok the value of software - and these are the organization that will be overtaken.
Tuesday, November 2, 2004, posted by @ 8:15 AM
Election Day
I cast my vote late last week, in order to avoid the long lines that were expected (and are indeed materializing) at the polls today. Vote early, vote often, is my motto :-)
I'm not one of the many undecided, but rather had made up my mind several weeks ago. Thusly robed in the extreme pleasure and honor of being able to cast a private vote in this democratic process, I strolled over to our local voting precinct - and waited about an hour to weave my way through the lines. When I finally got to the voting booth, I was surprised and delighted to note that our county had installed electronic voting machines. I wasn't able to read the label of the manufacturer, and I expected I'd draw some unwanted attention if I had reached around behind or under the machine to look. The use case for voting was really quite straightforward: the polling officer identified my precinct, picked up a block that matched my precinct and inserted it in the machine, brining up the appropriate ballot for me. Voting was easy to do on the touch screen display, and changing votes/going back was even possible (I know, I intentionally explored the edges of the use case). I wish a paper copy had been created; it seems like such a simple thing to do and, in this era of hanging chads and such, seems to be a prudent safeguard. I was also surprised to see that the machines had no UPS device; they were plugged straight into the wall - one wonders what checkpointing is done in the event power fails. While I'm on this riff of surprises, I'm also surprised that there were no obvious parity checks: having a manual count of voters per machine and then matching them to votes actually placed would be another simple and obvious check and balance.
As the day unfolds, I'll be glued to my favorite Internet radio and then hosting an election party where we'll watch the returns.
Sunday, October 24, 2004, posted by @ 8:15 PM
Architecture Sites
Recently, a couple of readers pointed me to their work, which I'd like to highlight here.
First, check out the work of Jeff Garland and Richard Anthony on Large-Scale Software Architecture on their site. I'd overlooked the publication of this book, but thanks to Amazon, a corresponding set of atoms should be flying itself to Colorado. Second, Vaughn Vernon pointed me to his project to codify enterprise architectures, with chapters being posted on TheServerSide.com. Thanks to both Jeff and Vaughn pointing me to their work
Amazingly, I'm not scheduled to be on an airplane for a least two weeks, so I hope to make a dent in the physical pile of notes I've collected for the Handbook
Friday, October 22, 2004, posted by @ 1:05 PM
Domain-Specific Languages
|I see that Microsoft is poised to make some announcements about their offerings for domain-specific languages next week. I'll keep an open mind, but as I've posted before, I'm skeptical.
First, while I agree that development is a team sport and that multiple stakeholders must collaborate in weaving together their diverse, interdependent views, one still needs to have a common semantic basis for all those languages. If you accept that not unreasonable position, you will end up covering the identical semantic ground as has the UML - albeit in an open manner, quite unlike Microsoft's historical record. Second, does one really need separate languages or is it sufficient to provide a common language with acceptable variations, as is the UML? As witnessed by the very slow take-up of C#, one may design a solid language but then you have to support that language, provide sites/papers/books/courses to help people become fluent in it, and in general build up a community of interest and a community of practice. If you do otherwise, you end up with just another isolated language that adds to the babble that every development organization already has to speak. Development teams need greater simplicity, not greater complexity, in their programming model. Third, will any such set of domain-specific languages be sufficiently long-lived that any reasonable development organization would be willing to commit its people and resources to that set? If otherwise, then such languages may be useful for writing totally disposable software only: remember that useful software tends to live on, although often retouched over time, and that means if the support for its expression evaporates, then your organization is, at worst, left hanging or, at best, forced to spend the overhead of porting that expression to yet another form.
Wednesday, October 20, 2004, posted by @ 11:05 AM
IBM Academy of Technology
I'm currently in Austin, participating in the annual meeting of the IBM Academy of Technology.
In an organization as large, deep, and broad as IBM, one ongoing challenge is the exploitation of cross divisional and cross-discipline integration. The Academy is an essential mechanism for IBM to bring this kind of integration about, primarily by throwing many of IBM's best and brightest into one mix so that connections can be made at deep technical levels. I just finished listening to a fascinating presentation on nanotechnology - where else could a software geek like me hear about the latest developments in this space, and get a coverage of the points of pain therein? Very high cool factor.
On a more pragmatic level, I connected with some of the folks who have pioneered performance and timing analysis tools for IBM's chip business. This is a field that's not only mature, but is pretty much at the core of all contemporary chip development processes. It didn't always use to be that way, but as the complexity of chips has grown, such best practices have proven essential to managing that complexity. In contrast, performance and timing analysis is highly underserved in most software shops except in obvious domains such as time-sensitive embedded systems. By way of reference, check out the pioneering work of Lloyd Williams and Connie Smith on performance engineering.
Tuesday, October 12, 2004, posted by @ 2:58 AM
Back From Japan
Just ahead of the latest typhoon I escaped from Japan, where I also survived a 5.7 earthquake as well as my keynote for the first IBM Rational Software Development Conference which drew around 1,500 attendees. I always enjoy my time in Tokyo: the city is quite electric (literally and figuratively), I can find the best uni, the Park Hyatt Tokyo is one of the classiest hotels in the world, and there are some very cool projects with which to work. Alas, at the moment, I'm attached to the web via a supremely inferior connection which makes it painful to even type, so I'll have to defer the juicy details until I find a fatter pipe.
I was asked a most interesting question by one of the Japanese press: do I see any differences in development styles around the world? Warning lights flashed in my head, telling me that this was a classic black hole and that crossing its Schwarzschild radius would permit me to offer a really stupid answer that in turn would shower me with hate mail and proffer a visit to the principal's office. Emboldened by terminal jet lag, I gave a politically correct response (i.e. one void of any identifiable useful information). In retrospect, however, I can make the following observations (which, I must add, are my own and not representative of any other person, living or dead, or of any large, multinational corporations whose initials are each one off that of HAL): moving from east to west, I find - very much on average - European developers to be more formal, US East coast developers to be more conservative, US West coast developers to be greater risk-takers, and Asian developers to be more methodical.
Please please PLEASE don't read too much into these broad generalizations, for the microclimate of each individual team is unique, and I mean nothing pejorative by any of these terms. In the end, software development has been, is, and will remain fundamentally hard, and each team has to face its own demons, wrestling them to the ground with all the best moves and practices and tools that they have at their disposal.
Wednesday, September 29, 2004, posted by @ 9:35 AM
Archeological Digs
I just returned from Silicon Valley, having met with a couple of local companies regarding their architectural practices. Two immediate observations from those visits: first, the essential architecture of most of interesting systems really is locked in the tribal memory of a few individuals and second, as such business mature, a focus on architecture becomes increasingly important as a means of driving economies of scale (by harvesting and then exploiting common architectural elements) and innovation (by creating the opportunity for entirely new businesses by opening up their architectures for integration with other systems of systems).
I spent some time with the folks at Adobe who were very gracious hosts. Part of my time was spent with the architect of Photoshop, digging through its architecture. Photoshop is the "professional standard in desktop digital imaging" according to their literature. Opening up the hood, there's a really beautiful and elegant architecture that lies within. The current release of Photoshop consists of about one million SLOC in C++, with several million SLOC of basic libraries written in a variety of languages. The 80/20 rule seems to apply here: the essence of the Photoshop architecture swirls around abstractions and mechanisms for documents, layers, channels, and tiles (some 20% of the total code) while the rest of the code is there for all the surrounding cruft (licensing, plugins, file manipulation, event handling, the user experience).
I also spent some time with a company who for the moment shall remain nameless, except for me to say that these guys are one of the dot com era's big success stories. They are running with a code base of about five million SLOC in C++ and Java, with a regular rhythm of releases that pushes out a new system very two weeks. It's really a joy to step inside a company where things seem to be clicking: they've got a good business model, they are growing and even hiring, and they are serious about improving their software development practices (which already are far better than the average I see in the industry). Above all, in both this company and Adobe, while there are always issues and risks to be addressed, their development teams seem to be having a good time, and that's always a sign of a healthy organization.
Wednesday, September 29, 2004, posted by @ 8:56 AM
Random News From Around the World
Last week, IBM reported that Blue Gene now holds the record as the fastest machine in the world, clocking in at 36 teraflops.
I track Dan Bricklin's blog and he's posted an interesting entry on Software That Lasts 200 Years.
Saturday, September 25, 2004, posted by @ 8:25 PM
Presentation On Software Architecture
I've been buried in books and papers these past two days, working to organize my thoughts sufficient to write a section on general software architecture for the Handbook. As I often do when I write, I like to lecture about what's in my head before putting fingers to keyboard, for it helps me to calibrate the coherency and scope of what I'm trying to say. I have a series of such lectures over the next two weeks, and so I've assembled a PowerPoint presentation on general software architecture.
I must offer my sincere thanks to Philippe Kruchten who is the source of many of the ideas (and some of the slides themselves) in this deck. I can't express enough how much I have learned from Philippe over the years: I believe I've said before that I've encountered only a handful of world-class software architects around the world in my career - and Philippe is one of them.
Thursday, September 23, 2004, posted by @ 7:57 AM
The End Of Civilization As We Know It
Sad news for developers around the world: the makers of Twinkies have filed for bankruptcy protection. I only pray that the makers of Jolt will remain strong in these turbulent economic times.
Wednesday, September 22, 2004, posted by @ 9:42 PM
Yoopeedoo
Check out Yoopeedoo, the site for a book on an educational software process based upon the Rational Unified Process.
Wednesday, September 22, 2004, posted by @ 11:45 AM
Clearing My Backlog
I've been off the air for a bit for purely mechanical reasons: it seems that the IBM developerWorks blogs have been moved 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 mirroring 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 remaning 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/aberrant/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 often 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 meaningfully 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 accordion.
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 in the artifacts.
Monday, September 13, 2004, posted by @ 3:37 PM
House Cleaning
I've cleaned up the Handbook site a bit by adding a common mechanism to access all of the papers, presentations, and other such references I've collected during the course of my blogging. As I shift my web development entirely to the Mac, I find that there are some annoying JavaScript inconsistencies between Internet Explorer and Safari that have cropped up, and so I'll need to waste some time to nail them down.
Also, I have a trip in the near future to visit the good folks at Adobe and eBay to study the architecture of their systems, so I've started to do some research of both before wheels up.
Friday, September 10, 2004, posted by @ 3:05 PM
Dating Design Patterns
Another one of my all-time favorite books is the Gang of Four's Design Patterns. As an indication of the broad applicability of patterns, check out Solveig Haugland's Dating Design Patterns.
20|2004-09-09|13:44:00|The Science of Design||One of my all-time favorite books is the late Herbert Simon's The Sciences of the Artificial. The Directorate of Computer and Information Science and Engineering of the National Science Foundation has kicked off an effort with some roots in Simon's work, on the topic of the science of design. Last November, the Directorate conduced a workshop on the topic, observing that "no major research effort has addressed the science of design in a comprehensive, systematic manner, with a particular emphasis on software and software-intensive systems." Indeed, this is one of the motivations behind my handbook: our industry is often so busy building things that we rarely step back and study how we built them.
I'm still slogging away on my research for the general architecture section of the handbook. The papers I extracted from the ACM and IEEE digital libraries have kept me quite occupied.
Thursday, September 9, 2004, posted by @ 1:44 PM
The Science of Design
One of my all-time favorite books is the late Herbert Simon's The Sciences of the Artificial. The Directorate of Computer and Information Science and Engineering of the National Science Foundation has kicked off an effort with some roots in Simon's work, on the topic of the science of design. Last November, the Directorate conduced a workshop on the topic, observing that "no major research effort has addressed the science of design in a comprehensive, systematic manner, with a particular emphasis on software and software-intensive systems." Indeed, this is one of the motivations behind my handbook: our industry is often so busy building things that we rarely step back and study how we built them.
I'm still slogging away on my research for the general architecture section of the handbook. The papers I extracted from the ACM and IEEE digital libraries have kept me quite occupied.
Wednesday, September 1, 2004, posted by @ 7:07 PM
A Geek's Tour
Dirk Riehle, a fellow board member of the Hillside Group, offers a most entertaining tour of Silicon Valley.
22|2004-08-30|16:27:00|"We're Lawyers...and we're here to help".
A frightening thought, perhaps, but as I've noted in a few of my public presentations, I expect that, lawyers will increasingly become a part of most software development teams, not only to assist in preserving intellectual property but also to help the team work its way through the minefield of patents laid down by other teams with bigger lawyers who passed that way before. The quote above actually comes from one of our lawyers, who reports to me that he's already seeing this come true.
Some time ago, Donald Knuth sent a letter to the Commissioner of Patents and Trademarks on the subject.
Monday, August 30, 2004, posted by @ 4:27 PM
We're Lawyers...
...and we're here to help.
A frightening thought, perhaps, but as I've noted in a few of my public presentations, I expect that, lawyers will increasingly become a part of most software development teams, not only to assist in preserving intellectual property but also to help the team work its way through the minefield of patents laid down by other teams with bigger lawyers who passed that way before. The quote above actually comes from one of our lawyers, who reports to me that he's already seeing this come true.
Some time ago, Donald Knuth sent a letter to the Commissioner of Patents and Trademarks on the subject.
Saturday, August 28, 2004, posted by @ 8:45 AM
Avoiding The Microsoft Tax
Today's news reports that Microsoft has set the release date for Longhorn in the second half of 2006, with a more modest collection of features relative to its initial announcement. I've yet to install Windows XP SP2 as I'm waiting for a few more pioneers to blaze the trail, letting them fall into the dark shadows first.
It may be the case, however, that I'll never bother installing SP2. I've decided to make the move to a Microsoft-free computing environment, having tired of the time I spend on the care and feeding of XP as compared to my relatively worry-free network of Linux appliances and Macs. My latest acquisition is a 17" Apple Powerbook powered by the IBM G4 processor which I'll use to replace my XP laptop and an older G4 tower. In addition to a breathtakingly beautiful form factor, this machine has every feature I need, from DVD-R to Airport and Bluetooth connections. More importantly, there's no essential application I need that doesn't run on this platform. In this manner, I'll avoid the Microsoft operating system tax, although I will break down and install the Microsoft Office suite (which actually is nicer on the Mac than it is on XP). Eclipse runs quite handily on the Mac already, thank you: I've been developing beans with it for over a year now.
Is it therefore curious for me, an IBMer, to be carrying around a non-IBM laptop? There's no doubt that IBM makes some wonderful personal computing devices (and I'm not quite to the point where I need a zSeries machine), but to paraphrase James Carville, "it's the software, stupid." In short, hardware comes and goes - and I'm very happy that dedicated hardware engineers keep coming up with better machines - but software lingers forever. Indeed, pretty much the only way to get rid of old software is to kill it. I've had data and applications in my modest environment that have persisted for almost two decades, but during that time I've blown through a number of generations of machines, each faster and with more capacity than the previous. When Longhorn comes out in a few years, I might take another look, but in the meantime, I have some real work to do and would rather not be distracted by the whining of a needy operating system that seems to come down with a cold every time I take it out into the world.
Friday, August 27, 2004, posted by @ 8:28 AM
Inventing The Future
I'm back from meetings at the IBM T. J. Watson Research Center in Yorktown (and, happily out of the city before the Republican National Convention). I can't really reveal what I was doing at the labs except to say that there's a group of Fellows from various parts of the company who have been brought together to lay some plans for IBM for the next decade. As Alan Kay once said, the best way to predict the future is to invent it.
I only read four books on this trip, so it was a slow week :-) but now that I'm back, I'm returning to the pile of architecture books I've collected, in order to finish the general architecture section of the Handbook. At the same time, I'm planning a trip to Tokyo and three different trips to the West Coast to interview some architects.
Monday, August 23, 2004, posted by @ 7:25 AM
On Being A Sys Admin
On a weekend in the '50s in middle America, you'd see guys clustered around some neighbor's hot rod, admiring the raw horsepower that could be unleashed and waxing philosophic about the merits of various approaches one might use to raise the coolness factor of the car. Well, here we are in the '00s, and last night I found myself with a handful of men and women in my wiring closet, admiring the raw MIPS of my web server and waxing philosophic about the merits of various wireless networking protocols.
As I've mentioned before in some of my public lectures, I'd built a very wired home for which being CIO is potentially a full time job. In all, we'd put about 5 miles of Cat5 wire in the walls (there are a couple of wireless nodes as well for those times when I want to take my laptop to bed or when I've got visiting IBMers in my conference room). I hired an installer to pull the cables, but I did all the termination and equipment installation myself because 1) if anything broke or needed to be modified, I wanted to be sure that I knew how to do it and 2) I figured that with all this practical experience in being a sysadmin/network engineer that maybe someday I could get a real job that my friends could understand. I should show you a network diagram (and I've got one, because my network has too many moving parts for me to keep in my head), but briefly, it all starts with a T1 coming from the outside to a router and then in turn to a dedicated Linux firewall appliance. The network splits out from there into untrusted and trusted subnets. The untrusted subnet is home to my web server and an application server (which fuses all the home audio, video, security, and telephony subsytems of the home and so both are locked down quite tightly) while the trusted subnet contains all the home components consisting of a handful of Macs and a terabyte file server with a streaming tape backup. I have a long list of things to do to the network, and even keeping all the latest security patches current and checking the logs for bad guys trying to push their way in is something that consumes time every week. Last night, I'd installed a security patch on my web server (an Apple Xserve, which BTW has an IBM processor inside :-)) which in turn caused a failure in MyMSQL installation. For those of you who tried to register/login to the Handbook the past few hours, my apologies for the inconvenience; I shall discipline my sysadmin severely. I should note that I'd received a handful of email messages telling me about the problem and very politely admonishing me for the profoundly lousy error messages my site reported (a "General Error"). Happily, it's just a simple matter of programming, not a systemic failure of my site's architecture, for me to provide a less user hostile response. Perhaps I'll host a programming party some weekend and get my friends to help.
Friday, August 20, 2004, posted by @ 12:21 AM
Addendum To Who's Who
It occurred to me while I was in the shower that I should have pointed out that my list of people only covers folks in the general software architecture and patterns space. In the course of my archeological digs, I've been making contact with the primary architects of each system under study; indeed, if I can't make contact with said architects I'm less interested in studying that particular system, because so much wisdom and history is locked up in their heads. Thus, I'll post references to these architects in the context of their respective system.
Friday, August 20, 2004, posted by @ 10:38 AM
Who's Who
I've just posted a list of contacts in the Handbook, naming some of the prime movers in the software architecture and patterns space. The web pages and email addresses therein are all publically visible elsewhere on the web, but please please please do not annoy, torment, pester, plague, molest, worry, badger, harry, persecute, irk, bullyrag, vex, disquiet, grate, beset, bother, tease, nettle, tantalize or ruffle any of these people. If you do, I will insult you, tell the world that your children are ugly, and then taunt you a second time.
Friday, August 20, 2004, posted by @ 7:28 AM
Professional Organizations
I've mentioned in the Handbook that "it is a sign of maturity for any given engineering discipline when we can name, study, and apply the patterns relevant to that domain." Another sign of maturity is the presence of professional organizations that codify knowledge and encourage development in a particular discipline. In civil architecture, there are a many such groups, including the American Architectural Foundation, the American Institute of Architects, and the Royal Institute of British Architects. For software architecture, there's just one, the Worldwide Institute of Software Architects. Codifying knowledge about software engineering in general has proven to be very difficult, as witnessed by the drama behind the work of the SWEBOK. Codifying a body of knowledge about software architecture is difficult in its own fashion, largely because so many of the best practices in software architecture live in tribal memory, not out in the open. In my professional career, I've probably met only a handful of world class software architects, many more very competent ones, and - sadly - more than a few really bad ones (years of experience and/or a particular job title do not bestow architectural skill).
Thursday, August 19, 2004, posted by @ 2:49 PM
General Software Architecture Papers
I'm going underground for several hours to pour through about 300 technical papers I've collected from the ACM and IEEE. In my conference room, I have physical copies of quite a few ACM and IEEE journals, each going back to the mid-70s, but when I'm blasting through the literature as I am today, using online digital libraries is far superior. Unlike the sites I grutched about in yesterday's posting, the printed literature has the advantage of being vetted through peer review in most cases, and so the signal to noise ratio is far above that found on the Web.
After I attend to my day job :-) and when I emerge from my reading frenzy, I'll start enumerating the most relevant articles I find (on the subject of software architecture, of course).
Wednesday, August 18, 2004, posted by @ 9:49 PM
General Software Architecture Sites
I spent several hours this evening surfing the Web for sites on software architecture. I must admit that it was a bit depressing. While I encountered a few vibrant sites (for example, the software architecture group at the Software Engineering Institute), most of the pages I uncovered were either dormant, horribly dated, or full of dangling references (and even the most vibrant sites seemed a bit stale to me). Granted, the Web is a fickle mistress when it comes to distinguishing pearls and swine, but I was surprised to find so few pearls. If it's any consolation, my sparse findings might be explained away by the Google IPO which looms tomorrow morning, for their search engines might be otherwise busy counting the expected billions.
Anyway, I did some digging through the muck so that you don't have to, and landed with a fairly small but useful collection of sites which I've documented in the Handbook (sorry, as I've explained before, you'll have to nominally register at the site, because it keeps out the spammers).
Wednesday, August 18, 2004, posted by @ 10:24 AM
General Software Architecture
I've been working on various bits of the Handbook this week, refining some of the text and researching the section on general software architecture. To that end, I've been pouring through the 30 or so books on the topic that I've collected over the years (you can see the entire list of books on the Handbook site) and am also assembling a set of links of online resources. If you've got a book, paper, or site to recommend, please shoot me an email so that I may include it.
Thursday, August 12, 2004, posted by @ 7:50 AM
Looking Forward
Among other things, I manage the relationship between IBM Rational and IBM Research, which means that I engage with Rational's strategy team and project managers to identify the wicked problems that we'd like to have Research pursue for us and then work with the Research teams to bring that work to fruition. The time horizon of the projects we've funded ranges anywhere from the present (meaning that we'll bring this work to product immediately) to one to three years out.
I've often called Research our secret weapon because it gives us an opportunity to spend energy on some big plays as well as some really knotty problems, in a setting that allows innovation to flourish but that is yet still connected to reality. I just completed a couple of days of meetings at Research to plan our agenda for 2005, and I've come back quite energized. Since I know that there are some Rogues from Redmond who read this blog (Hi Steve! Hi Wojtek!) I won't go into extreme details here, but suffice it to say that there are still a lot of hard problems to solve in the area improving the developer experience. One important theme that came out of our discussions was the importance of and the opportunity for seamless and deep semantic connectivity among all the artifacts of the development process; another critical theme addressed tooling for legacy systems, tooling that would help conducting architectural digs and recomponentizing such systems for delivery as services.
Friday, August 6, 2004, posted by @ 4:28 PM
Systems Under Investigation
As I promised earlier this week, I've released a few new findings from the archeological digs I'm conducting for my Handbook of Software Architecture. For those of you familiar with this project (and for those of you who are not, surf to the site and register), you may recall that I've been advancing on several systems at once. Originally, I'd designed the site to expose each system publically only once it was completely documented and vetted by the original development team. I made a subtle change in permissions for each part of the site such that any registered user can now visit the overview of any system whose architecture is currently under study (although the details of each architecture will still be kept hidden except to the original developers and myself and until such time that the findings has been vetted).
I'm working on about a dozen different systems at once - there's latency in the various phases of investigating each one, and so parallelism is possible - and finally I've begun to capture my findings on the site. Specifically, if you enter the site and then traverse to Systems (View by Status) you'll be able to see a few systems marked as selected. In particular, BMW's iDrive, OOCL's IRIS-2, JPL's Mars Exploration Rovers, and Massive now have content that you can visit.
Happily, it was easy to make this change to the behavior of my site: I had to add one new method to one bean and add/modify only seven lines of code on two pages. Yes, my entire site is modeled in the UML and so determining where I needed to touch the system and then make the changes (and then test those changes, of course!) only took about an hour of my time.
Thursday, August 5, 2004, posted by @ 10:24 AM
Development As A Team Sport
A colleague at IBM passed on to me an article about the software development team, a piece I'd written seven years ago (and had totally forgotten about). Its message still applies: software development is a team sport. It seems to be a dirty little secret among some of the platform vendors that developing software is fundamentally hard: too often applications and middleware are positioned as being the breakthrough that will change your life, make your teenages like you, and whiten your teeth. Reality is that developing software has been, is, and will remain hard.
Continuing on the team riff, I must point you to an incredibly wise book by Jim Coplien and Neil Harrison, Organizational Patterns of Agile Software Development. Run, do not walk, to your nearest bookstore to buy a copy of this book. These days when I walk into a Borders, Bares and Noble, or (my favorite) Tattered Cover, I get depressed walking the aisles of computer books: most manuscripts are little more than extended documentation for desktop products and while I respect many of these authors and their hard work, there are very few books that offer something really wise and wonderful. I'm jazzed about Cope's book because it is one of the few really good books I've seen of late.
Wednesday, August 4, 2004, posted by @ 1:38 PM
Architectural Mechanisms
Every software-intensive system has an architecture: some architectures are intentional while others are accidental and some are explicit while others are locked up in the tribal memory of its developers. I've long contended that the soul of every architecture is manifest in the mechanisms that shape a given system. By mechanism I mean, in essence, the design patterns that individually provide some essential structure and behavior and that collectively offer a language of patterns that are uniquely suited to the given domain.
For example, I've been studying the architecture of various operating system kernels lately and it's clear that every one of them covers the same ground although each in a unique way. For the most part, if you understand a given operating system's approach to device drivers, the file system, thread and process management, networking, and primitive services, you will have understood the essence of that system's architecture. It should be pointed out, however, that which mechanisms apply is a statement of architecture in itself: other systems in other domains will have a very different set of mechanisms.
Monday, August 2, 2004, posted by @ 9:36 AM
Classification
For those of you who are following my work in The Handbook of Software Architecture, I'll be posting some updates later this week on the various systems I've been studying. Trying to cover a set of systems that's reasonably representative of the breadth of software-intensive systems is challenging mainly because of the embarrassment of riches that lay before me: there are so darned many interesting systems to study, I have to walk away from many more of them than I'll ever be able to study in a lifetime.
Grouping these systems into meaningful categories is a classic problem of classification, and there's clearly no right or perfect answer here For example, is Massive an artificial system or a content authoring system or both? Is content authoring even the proper collective name for text, audio, and image editing systems? My hypothesis is that there really are only a few distinct architectural patterns that shape every software-intensive system, but then the various shades of architecture are formed by the mixture of mechanisms (think design patterns) that weave through those architectural patterns. For example, Massive at its root looks sort of like a blackboard system but also has a considerable amount of plumbing necessary to push out scenes to other systems such as RenderMan.
Now that I think about it, it's increasingly difficult to find software-intensive systems that are completely isolated: every system seems to be connected to some others. As the world moves to continuously evolving systems being the norm, perhaps we'll find that every piece of software is only six degrees of separation from any other.
Sunday, August 1, 2004, posted by @ 2:49 PM
General Software Architecture Papers
I'm going underground for several hours to pour through about 300 technical papers I've collected from the ACM and IEEE. In my conference room, I have physical copies of quite a few ACM and IEEE journals, each going back to the mid-70s, but when I'm blasting through the literature as I am today, using online digital libraries is far superior. Unlike the sites I grutched about in yesterday's posting, the printed literature has the advantage of being vetted through peer review in most cases, and so the signal to noise ratio is far above that found on the Web.
After I attend to my day job :-) and when I emerge from my reading frenzy, I'll start enumerating the most relevant articles I find (on the subject of software architecture, of course).
Friday, July 30, 2004, posted by @ 9:52 AM
Imitation Is The Sincerest Flattery
It's been fascinating to watch Microsoft try to follow the very path that Rational forged a lifetime ago, namely, the creation of a suite of tools that support the software development lifecycle, not just the activities of coding. The latest brick in this well-worn path that Microsoft is walking is their vigorous pursuit of patents, something which will require a bit of catchup since IBM has led the world in patents for the past 11 years (and shows no signs of letting up).
What strikes me the most about this latest move from Redmond is that it represents a subtle yet significant recognition of the critical importance of improving the activity of software development by teams - not just individuals - and the protection of essential software intellectual property as a means of driving innovation and economy. I'd recently been interviewed by Jack Vaughn of Application Development Trends and he rightly observed that the futures pitch I gave at the Rational Software Development User Conference was optimistic (and he suggested that was a welcome sign given the current state of our industry). I'd observed in my keynote that what sent chills down my spine in looking at the future not of our industry but of our world was that every advance required software that had not yet been written.
In short, there's still a lot of exciting stuff we'll get to do in the coming years.
Wednesday, July 28, 2004, posted by @ 8:39 AM
The Software Professional
Historically, it seems that I do my best writing in the hours between midnight and dawn (I generally don't need a lot of sleep). However, there are many times in my life when it becomes difficult to push back the constant noise of phone calls, email, instant messages, and snail mail, such that I find it best to run away to a region with fewer transistors than normal in order to write. That's what I've been doing the last couple of days, and so - while coming up for air for a few minutes - am blogging from the mountains of Colorado. Yes, wireless high speed Internet connections are even available at 14,000 feet above sea level. Ain't technology wonderful?
Speaking of technology, over the past few months I've had a handful of software professionals lament to me about the state of the industry and how they would never encourage their children to enter the field. There is no doubt that the global economic malaise continues in our space, manifest by ongoing consolidation, fewer small companies in the mix bringing out-of-the-box ideas to the market, and underperforming companies in the middle struggling for survival. Couple that with very real angst that individual developers experience over layoffs and the global relocation of jobs and it is indeed grim from some angles. On top of that news, a number of reports acknowledge a global decline in the number of students graduating from universities with some sort of degree in software.
When I talk to non-software audiences, I'm still stunned by how many such folks simply don't have a clue what software is about. All too often when non-technical people ask me what I do I'll say that I'm in computers and they'll reply by saying, "oh, my son/daughter/cousin/nephew is in computers too!" but when I probe, I realize that most of the time they mean that their son/daughter/cousin/nephew knows how to install the latest Windows patches and/or can plug in various USB peripherals and make them work most of the time. I'll usually smile and reply with a polite "how interesting," but then when I try to explain what I do in software, their eyes generally glaze over. For most of the world, what we do in our world is still very intangible and mysterious.
I can't speak for my colleagues, but personally I am still very much excited by the potential of software and the opportunities that exist for innovation by individuals in the field (the US Department of Labor has similar optimistic views). For this reason I continue to encourage the children and young adults in my life to pursue work in software. Some of that generation will likely enter our field directly, but I expect that most of the next generation who dabble in software will do so not as a software professional but rather as a domain expert in some specific field that requires extreme skill in using and writing software for that domain.
Friday, July 23, 2004, posted by @ 9:21 PM
Ultrasound
I'm back from the radiologist office. We baselined my aorta and happily all my internal plumbing was deemed intact, a most welcome report given the news in my earlier post regarding the death of my nephew, Thomas.
As I usually do when surrounded by technology, I engaged the nurse with questions about the equipment she was using. This particular ultrasound machine was from General Electric and cost around $300,000. I learned that ultrasound hit the mainstream in the 70's and at that time permitted only static images. As computing power increased, real time ultrasound was possible, permitting the analyst to explore interesting images using visual feedback. All of the images they took today were digital (I observed with no little trepidation that their image servers ran an older operating system from a certain company in Redmond...oh how I hope they are fastidious in downloading the latest of the continuous flood of patches). The user interface with the system seemed clumsy, with the nurse having to take her hands off the probe to type from time to time. I'm told that the next generation machines permit voice input, thus freeing the operator's hands and streamlining the process (the nurse has to mark certain interesting features so that things like aorta diameter and wall size can be determined). I was also told that this next generation was just a software upgrade away; they'd be able to preserve their investment in the hardware.
Indeed, software is everywhere. In the past X-rays would use traditional film, but in my test today, the machine took digital images directly.
Friday, July 23, 2004, posted by @ 11:25 AM
Lectures from the IBM Rational Software Development User Confere
At the RUC earlier this week I offered two presentations, the first a keynote celebrating the 50th anniversary of Rational's founding and the second a presentation on software archeology.
Thursday, July 22, 2004, posted by @ 1:56 PM
Digital Domain
Yesterday morning, I had the pleasure of dining with Scott Ross, president of Digital Domain, the company responsible for the special effects in Titanic, What Dreams May Come, Apollo 13, True Lies, I Robot, and many others. Special effects are a computationally expensive endeavor that moreover require significant and innovative artistry. Scott observed that the past few years have witnessed a number of algorithmic breakthroughs on the path to complete photorealism: in this general order, the proper rendering and animation of clothing, hair, and now facial features. Scott went on to note that the windows are the eyes of the soul, and this particular facial feature is really the one remaining problem to tackle. Digital Domain probably models fluids better than anyone in the business (see, for example, The Day After Tomorrow), but as far as photorealistic rendering of humans are concerned, the industry is already there, according to Scott. Actors who inconveniently die in the middle of production may be brought back to life, stunts that would be far too dangerous for any human to undertake are carried out digitally, and individuals, crowds (both human and otherwise), and sets are regularly added to films to supplement or replace artifacts in the real world. This is not to say that virtual actors are the future and that the artistic lifetime of human actors is numbered. From my perspective outside Hollywood, the situation seems very much the same as with the growth of electronic synthesizers. When these devices really hit the mainstream in the 70s and 80s, everyone was afraid that musicians would be a dying breed. Well, synthesizers are still mainstream and they have permitted marginal artists to produce dreadful music much more rapidly than they could in the past, but they have also unleashed new forms of expression. Ultimately, good art and talented artists survive the introduction of new technology and are actually empowered by it.
Back on the software side of the special effects business, it's interesting to note that a handful of products dominate the industry (for example, Pixar's Renderman and Maya) although each effects house gets its particular competitive advantage from proprietary software. In addition to raw rendering and animation, the production problem is ultimately one of complex workflow, involving a pipeline that starts with the director, artists, and actors and ends with final scenes. Keeping that pipeline filled, especially during post production, is what distinguishes an efficient process from a dysfunctional one (the latter of which gets you reported in Variety and ultimately results in missing box office opening dates).
One parting observation on the connection of software to Hollywood: Steve Jobs founded Pixar and Paul Allen is a major investor in Dreamworks.
Thursday, July 22, 2004, posted by @ 11:05 AM
Saving Myself
I posted my last blog on Tuesday, June 29th. The very next day while I was in Venice, I received a call from my only sister who reported that her only son died in his sleep of an aneurysm at the tender age of 20. Thomas was an amazing individual: he was in his final year at Vanderbilt University, was a few days away from traveling to Cambridge for the summer, and had just been accepted to the Yale School of Medicine. He was a young man of faith and passion beyond his years, an accomplished pianist, and in all respects a gentle and caring soul. He will be missed. My wife and I have no children, so this loss is doubly felt as this also represents the terminus of the Booch genes.
Because I was still in Europe, it was physically impossible for me to make it back to the United States in time for his funeral although I did spend time with the family immediately upon my return (and I just now returned from keynoting the IBM Rational Software Development User Conference which I'll talk about in a later post). Needless to say, keeping up with my blog was low on my list of priorities at the time.
I've known for many years that this was in my DNA. My father died of an aneurysm as did his brother, although both did so in their late 70s, a much more common time for men. I'd recently had a complete physical and just a couple of years ago tested for aneurysms. Needless to say, this recent episode has caused me to be much more aggressive in diagnosis (I've got an appointment with the doctor this Friday to baseline my aorta). The symptoms of an impending aneurysm are often silent, but one can get indicators via X-ray and CAT scan.
CAT scans, by their very definition, are software-intensive devices. Siemens, Toshiba, General Electric, and Philips are among the leading manufacturers. I titled this blog as Saving Myself because I actually have engaged with some of the teams in these companies and are aware of a few of their projects and practices. The theme of the Rational conference was software runs the world, and this is brought to a clear and present reality for me, as whatever I can to to raise the tide of quality and professionalism in the field of software engineering may indeed contribute to saving myself in a very literal sense.
Tuesday, June 29, 2004, posted by @ 5:00 PM
Almost Home
I've finished my work in Paris and having toured around the French Riveria for about a week, I'm now in Milan. One thing I found most remarkable about the Riveria: people with far more money than time seem to pour their euros into enormous yachts. When I was in Florida recently, I saw the smallest of Paul Allen's three yachts, the Meduse. His largest yacht - which also happens to be the world's largest privately owned yacht - is the Octopus, coming in at over 413 feet, and equipped with its own helicopter and submarine.
Naturally, my first question upon seeing any such vessel is simply, what kind of software is inside? Clearly, I'll need to do some on-side studies to get a full answer.
Sunday, June 20, 2004, posted by @ 10:28 PM
Dave Parnas
I had an absolutely smashing time in Dublin, meeting with various representatives of Science Foundation Ireland, faculty from the University of Limerick and Dublin City University, and scientists at the IBM Dublin Laboratory. David Parnas has landed at Limerick, where he leads the Software Quality Research Laboratory.
At this moment, however, I'm back from Dublin and in the romantic city of Paris, having just finished an amazing meal at Fonquet's. Tomorrow, I'm meeting with various clients and journalists in the city.
Thursday, June 17, 2004, posted by @ 10:31 PM
Linux Sighting
At this instant, I'm in Dublin, having just missed Bloomsday by 24 hours.
On this trip, I flow over the pond via Virgin Atlantic, and was much amused by their entertainment system, which provides a cornucopia of movies, television, and games. If you watch closely while the aircraft boots, you can watch the start up log of Linux on each passenger's display. The booting process is slow - the system has to boot several hundred displays - but once launched, Linux becomes invisible (as should any Good Operating System).
Friday, June 11, 2004, posted by @ 2:54 PM
Grand Tour
I'm off to Europe again on Monday with customer work in London, Dublin (not to be confused with Dublin Core), and Paris (definitely not to be confused with Paris Hilton). I'll be back after the 4th of July, so as with my previous trip over the pond a few months ago, will only be able to blog sporadically as I'll be traveling sans laptop and therefore at the mercy of hotel business centers and Internet cafes. I try to spend about 30% of my time with customers and in the field...you should never trust a methodologist who does not use his/her own work.
You may ask why I travel internationally intentionally disconnected from the grid. Well, it's not as bad as Don Knuth who has no public email address, but there are two reasons, actually. First, given my looks, I'm already profiled enough at airports around the world, and having a laptop simply increases the friction of travel for me. Second, email is already the bane of my existence, and being away from it for a while is incredible refreshing (and a reminder that the majority of the world is distinctly not tethered to the Web). On a typical day I'll receive around 100-200 non-spam messages. If it's important, people who know me can reach me by phone; if it's really important, people who really know me can reach me on my mobile; if it's really really important, people who really really know me can reach me via my personal email account.
Thursday, June 10, 2004, posted by @ 9:15 AM
UML First Principals
Simon Johnston has recently joined our merry band of IBM bloggers (welcome, Simon!). In a recent post, Simon offered his reaction to an article by Keith Short of Microsoft regarding the UML versus domain-specific languages (DSL).
I violently agree with Simon's world view. The essential value of the UML remains unchanged from its creation: the UML is a simply a graphical language for visualizing, specifying, constructing, and documenting the artifacts of a software-intensive system. Ultimately, the UML is all about providing a language of expression for better understanding and reasoning about a system. To that end, the UML doesn't replace traditional languages such as Java and C++, but rather, the UML stands as a peer. Trying to grok a continuously evolving system that has tens of thousands of moving parts most likely running across multiple machines loaded with multiple platforms and built out of parts from multiple languages is just plain hard: the UML provides a language for expressing many of the structures and behaviors that span this cacophony. Having the right language of expression for a given problem does wonders in melting away complexity, as the work of Edward Tufte shows (and Tufte's work greatly influenced my contributions to the UML). Keith draws a line in the sand between the UML and DSLs which essentially relegates the UML to nothing more than a primitive language for whiteboards (and then promotes Microsoft-specific DSLs for "real" development).
I, as does Simon, actually agree with Keith's view that the UML is absolutely brilliant as a common language of communication on whiteboards and napkins (and I'm tickled to get confirmation that such UML diagrams show up on Microsoft developer whiteboards). However, I think, as does Simon, that Keith misses the point when he distinguishes DSLs as something totally different from the UML. The last thing the world needs is yet another (non-open standard) programming model or language injected in an already complex space. Our experience has shown that domain-specific design and architectural patterns specified can (and should be) expressed in the very same language that one may use on a whiteboard or napkin, namely, the UML. Furthermore, in the real time space, there are already existence proofs of direct executability of UML models (see, for example, Rational's own Rose Real Time as well as David Harel's Play Engine).
One of the metagoals of my Handbook is to show that the UML is appropriate for modeling a large spectrum of software-intensive systems, from Amazon to the Spirit to Massive; thus far, I've not be disappointed or limited by what I can do in the UML.
Wednesday, June 9, 2004, posted by @ 5:04 PM
Supercomputing
One of the genres of systems I'm studying for the Handbook of Software Architecture is that of supercomputing. There are several classes of problems for which deep computing is essential: modeling the weather, protein folding, materials analysis, and so on. I've mentioned the Top 500 list before, but there are two recent additions to the list worth mentioning.
Now listed as the world's third fastest computer is the relatively inexpensive System X built at Virginia Tech, consisting of a supercluster of over 1,000 Apple Macintosh G5 machines. (It's also worth noting that G5 chip is produced by IBM). Number 73 on the list is IBM's Blue Gene prototype, the operative word here being prototype. The first production machine, being built for the Lawrence Livermore Laboratory, is expected to hit 360 teraflops, almost an order of magnitude faster than the current leader, Japan's Earth Simulator.
Being a software geek, I'm therefore naturally curious as to the software architecture of such systems; I have knowledge of command and control systems, enterprise systems, robotics, games, and embedded systems, but admittedly have a blind spot in software for deep computing. What I have learned this far is that the ability to build large scale software for this domain is becoming an increasing bottleneck to exploiting the power of these amazing machines. FORTRAN and C still appear to be the dominant languages here, with Java starting to gain some traction.
Monday, June 7, 2004, posted by @ 10:08 AM
First Principals
I have just been slammed with travel, so apologies for my radio silence. I'm just back from two weeks in Europe followed by ten days in Florida, I'm just a few hours from wheels up to San Francisco, and then next Monday I'm off again to Europe for the remainder of June, doing some work in London, Dublin, and Paris.
I'm so looking forward to today's trip. As I've described in an earlier posting, I've started a project with the Computer History Museum to preserve classic software. A few weeks ago, the source code to MacPaint fell into my lap (thanks to help from Tim O'Reilly). Tomorrow, I'm conducting an oral history on MacPaint with Bill Atkinson and Andy Herzfeld, two of my heroes.
Studying the source code to MacPaint (which is written in Object Pascal) is a delight. Don Knuth calls it one of the most beautiful pieces of software he's ever read. Its curious, you know: people in most other disciplines learn by studying the artifacts of other masters, but I've yet to see a computer science course titled Readings in Software (Code). There is fortunately a new book that finally does cover this subject which I'd highly recommend, Code Reading by Diomidis Spinellis. Don's work in literate programming is also a good source.
What makes for beautiful software? The dot bomb era was fully of profoundly stupid business models, but in retrospect, it did tell us one thing: solid engineering never goes out of style. For me, that means building software-intensive systems that follow just three fundamentals: craft crisp and resilient abstractions, maintain a good separation of concerns, and create a balanced distribution of responsibilities.
Friday, May 21, 2004, posted by @ 9:56 AM
Expansion Of The UML
I was delighted to see today's report that Sun has announced support for the UML in their tools. This comes on the heels of Microsoft telegraphing their support for modeling in various public presentations, although the crew in Redmond seem to trying to downplay the UML open standard in lieu of non-UML domain-specific languages (DSL). I must admit that I'd always found the DSL play to be one of classic over-engineering (the notion of DSLs are not new, as they factored in some of the proposals for UML 1.0). The UML has proven itself valuable in essentially every domain of software-intensive systems (and my project to create a handbook of software architecture continues to demonstrate that is the case). There is no doubt that different domains and different stakeholders are best served by visualizations that best speak their language - the work of Edward Tufte certainly demonstrates that - but there is tremendous value in having a common underlying semantic model for all such stakeholders. Additionally, the UML standard permits different visualizations, so if one follows the path of pure DSLs, you essentially end up having to recreate the UML itself again, which seems a bit silly given the tens of thousand of person-hours already invested in creating the UML as an open, public standard. In the end, I'm more encouraged by pattern languages offering a better path to domain-specific value. Every domain and every development culture has its own tribal memory, and patterns thus far have also proven themselves sufficient and valuable in codifying much of that memory, especially insofar as it relates to design and architecture.
Anyway, I'm actually happy that Sun and Microsoft have entered the modeling playing field (we've realized the value of modeling for years, he said shyly). This is not just a marketing play for them, but appears to be continuing validation of the importance of modeling to the creation of software-intensive systems. As I've said many times, the entire history of software engineering is one of rising levels of abstractions, and modeling languages such as the UML are consistent with that trajectory for the future.
Thursday, May 20, 2004, posted by @ 9:00 AM
Patterns Of Patterns
I've been enjoying Christopher Alexander's latest book, The Nature of Order, which - although it sometimes dives into the metaphilosophical - is a very approachable and visually appealing romp through the patterns that shape our lives and the places in which we live. The style of Christopher's book reminds me of Marvin Minsky's seminal work, The Society of Mind.
Speaking of patterns, I regularly track the comings and goings of Microsoft and their efforts in patterns (as Michael Corleone in The Godfather said, "keep your friends close and your enemies closer"). Offering equal time to IBM, we also have a patterns portal.
Tuesday, May 18, 2004, posted by @ 10:11 AM
Sojourner
Let me highly recommend the book Sojourner by Andrew Mishkin, who lead the team that took the rover on its journeys across Mars. Andrew's book is very much in the style and passion of The Soul of a New Machine by Tracy Kidder. The story of the Pathfinder mission is engaging unto itself, but if you read Andrew's book as a software geek, you'll get some excellent insights into the scenarios that surround the Sojourner's mission (EDL - Entry, Descent, and Landing - for example) as well as some details as to its architecture (there's a great riff on the problems of Pathfinder/Sojourner radio communication which uncovers some of the hardware/software tradeoffs that were made). Andrew and team are still incredibly busy folks, with the Spirit and Opportunity missions still in play.
You think building a continuously evolving enterprise system is hard? Consider then writing the software for a semi-autonomous device that you can only talk to at very, very low data rates from a distance of some 35,0000 million miles, software that must interact with dozens of hardware devices in a very hostile environment (so hostile, in fact, that one of the design considerations is the reality that the very wires that lead from the computer to outside the rover's shell are heat conductors, which therefore draw heat from the inside to the Martian environment).
Friday, May 14, 2004, posted by @ 3:00 PM
OOCL
I was reading the Economist the the other day (isn't that on every geek's reading list?), when to my surprise I saw a full page ad with a portrait of Ken Chih, the CIO of OOCL. The Orient Overseas Container Line (OOCL) is one of the world's largest integrated international container transportation, logistics and terminal companies. I'd worked with Ken and his team about six years ago on a project and had an incredible amount of fun; not only was his team focused, high energy, and dedicated, they were engaged in an effort that was really a make-or-break deal for the company. This is a company that understands the power of information technology to innovate. This is also a business domain that is very, very dynamic, with opportunities for satellite tracking of individual containers and simultaneous pressures to provide more secure shipping in this current age of international terrorism.
And who would have imagined a generation ago we'd ever be talking about the software implications of terrorism?
Thursday, May 13, 2004, posted by @ 10:40 AM
Legal Issues
IBM is a strong believer in patents, having again in 2003 led the world - as it has for the past 11 years - by filing over 3,000 patents. Establishing defensible legal mechanisms for the protection of intellectual property within software is a vibrant and dynamic domain, with companies doing everything from nothing to copyright to aggressive patenting and attendant licensing of those patents. It's my personal opinion (and not that of any person living or dead and certainly not of any organization with which I'm affiliated) that the law is still playing catchup with software and that the various patenting offices around the world have struggled as well, in some cases rejecting quite legitimate patents while at the same time letting slip some overly broad and distinctly strange patents into the mix. I'm not a legal expert, so I won't begin to speak of these legal mechanisms; I'm also not an MBA, so I won't begin to comment on patenting as a corporate mechanism. However, from the perspective of a software professional, I have two subjects for consideration.
First, the presence of patents is steadily growing as an engineering force upon development teams. We are not quite at the point where every code warrior needs to pair program with a lawyer, but it is the case that many development teams are probably happily coding away not realizing that they are in violation of some patents which they otherwise might perceive as obvious prior art. This brings us back to the corporate mechanism of patents and cross-licensing, so I won't go further with that issue.
Second, studying patents is an amazingly valuable way to learn about and understand existing architectures. Using patented information to build a system is a clear violation of the law; talking about or describing the intellectual property within a patent is legal, for patents themselves are public information (and most software patents contain a considerable of design detail). I don't have the exact number, but IBM was awarded a few hundred software-specific patents in 2003; Amazon has just under 50 patents total in its portfolio in the United States, each of which is an interesting study in one aspect of their system's architecture and which I'm studying as I pursue an archeological dig therein).
In addition to Amazon's system, I continue to advance my study of the JPL Spirit's software architecture. Spacecraft are actually on the US Munitions List and so are protected under federal export control. Disclosing source code would be a clear violation of these federal statutes, disclosing certain algorithms might even land me in jail (can I get a cell near Martha?), but disclosing the architecture of something like Spirit is fuzzy, since a considerable amount of these high level design decisions are already publically available in bits and pieces throughout various technical and trade journals. Nonetheless, this is an area where the legal ground is soft and in some places total virgin territory, but territory where I'll be treading over the coming months.
Monday, May 10, 2004, posted by @ 9:51 PM
Back Online
My body returned from London a few days ago and happily my soul finally caught up with it over the weekend. As expected, I was faced with over 5,000 new email messages and 2.75 feet (from top to bottom) of snail mail. Email is such a broken medium.
In addition to catching up on the most urgent email over the weekend (and reminding my cats that I was still their servant), I took the time to finally upgrade the operating system on my home server (from the Mac OS Server 10.2 to 10.3.3). I run an Apple Xserve (although it's an Apple machine, remember that IBM makes the 58 million+ transistor processor at their Fishkill facility). Migration was fairly painless, except that my outgoing email was broken for a few hours until I tracked down one obscure setting that hadn't quite made the transfer. One great new feature is the ability to apply a dynamic real time black list to the SMTP pipe. Migrating my web site was a bit more problematic, as all my Java server pages were broken at first. With the help of a remote pair programmer, I tracked my problem down to a known issue in the latest Tomcat release which required me to fiddle with the packages in which my beans live. Testing the site revealed one other bug that affected my Wiki-like facility for in place editing; turns out that the root of my sites changed subtly in the transfer, and I had to adjust some classpaths. After about two hours of digging and testing and then 10 minutes of actually recoding (I had to change one line in one bean), my primary site popped up all fresh and shiny. Although this site is a modest venture, it does point out the reality that a lot of interesting systems are continuously evolving, meaning that you can never turn them off although they consist of (for systems of scale) hundreds of thousands of moving parts each of which may be changed nearly independently of the other.
Tuesday, May 4, 2004, posted by @ 10:16 PM
Taking A Bath
I'm in the beautiful city of Bath in the United Kingdom. My search for a public Web cafe actually led me to the reception desk at my hotel, where I kicked out the staff for about half an hour while I blogged. I seriously hope no one needed to book a room, for I was the bottleneck at the front desk. Happily, no guest came up to me asking for services; my American accent surely would have given me away (although, having done a number of Shakespearian plays in my misspent youth, I suppose I could have conjured up some suitable voice).
This being a very historical city, I'm reminded of the following. Some archeologists were digging through the city, and first came upon some fiber optic cables. Below that were some Cat5 cables, and below that were plain copper, then older cables with fabric insulation. Below that was nothing, whereby the archeologists could confidently conclude that the ancient Romans had indeed discovered WiFi.
Obviously, I've been on the road too long and too long separated from a critical mass of transistors. I doubt I'll be able to blog until my return on the 7th, so thanks for your patience until I return to a more software-intensive world. I shudder at the piles of email that likely await me: with an average of 200-300 emails/per day and 15 days of unread email...well, you do the math.
Friday, April 30, 2004, posted by @ 6:58 PM
Drip, Drip, Drip...
Oh, how I long for the sun. I'm currently along the (very wet) southern coast of the United Kingdom, having finished some work at IBM Hursley. Among other things, I spent time with the teams working on aspect-oriented programming.
While on the road, I still find myself network-challenged. The hotel I'm in has a slow 64kb line, and loading pages seems like a struggle. Well, at least I have access, which is an improvement. I suppose that one has to be patient when expecting 15th century buildings to be rewired for Cat5.
Wednesday, April 28, 2004, posted by @ 6:27 AM
In London
I'm just back from Oxford having given my lecture there, and am now in London about to lecture at Imperial College in London. The weather here is wet and overcast, a rather typical London day.
I tried to blog from Oxford, but a) my hotel had no high speed Internet connection, then b) the largest local Internet cafe was closed for renovation, and yet c) it was sufficiently late such that anything else was closed. Students at Oxford have told me that this is a curious college town, in that pretty much everything closes up early. I suppose everyone is too busy studying to warrant such services. Those same students do report that all the colleges are quite wired with both fixed and wireless connections. Nonetheless, my travails in searching for public access remind me of a decade ago when, before mobile phones become so pervasive, one had to search for public phones. In the generation before that, phones themselves were rare commodities and one would have to hunt for any phone. In the generation before that even, I suppose one had the same experience with tracking down a telegraph station (in fact, there's a delightful book on the subject, The Victorian Internet).
Well, I'm off some some fish and chips to fortify myself before I lecture...
Sunday, April 18, 2004, posted by @ 10:26 PM
Not a Booch
I was introduced for a presentation recently, wherein the host remarked that I'd written something upwards of 30 books. I had to correct him - I've only written six books - but it made me curious as to what works I'd been linked.
For example, a Mr. B. Booch has written Hunting Boar, Hogs, and Javelina. We may be related and although I've eaten boar (I'm somewhat of an omnivore), I've never shot one much less am an expert at hunting them. There's also the classic children's book, The Nunqu Punga and the Booch by Jean Kennedy. Additionally, some years ago, a programmer in southern California had a contest to name their dog, and the winning name was Grady Pooch (a different Pooch than the Booch dog).
As for other Booch sites, a gentleman has formed The Church of Grady Booch. There's an alternative Booch blog, although this one is by a young woman at Princeton. There's even a Booch DJ and a Booch Festival. Finally, the Urban Dictionary has about a dozen definitions of Booch, although Dude, that game was booch is my favorite.
Saturday, April 17, 2004, posted by @ 3:18 PM
Sites and Such
In an earlier posting, I enumerated all the journals and sites I read/visit regularly. I've since added two other sites to my collection of visit-at-least-once-a-week pages, the posting of Carl Shirky and Bruce Tognazzini.
Saturday, April 17, 2004, posted by @ 12:15 AM
Strachey Lecture at Oxford
I've finished my presentation for the Strachey Lecture in Computing Science. In addition to this presentation at Oxford, I'll be lecturing at Imperial College, the University of Southhampton, and the IBM Hursley laboratories.
Friday, April 16, 2004, posted by @ 3:28 PM
Microsoft Architects Journal
I'm a little behind on noticing this, but check out the Microsoft Architects Journal.
Thursday, April 15, 2004, posted by @ 10:21 AM
Boulder JUG
This evening, I'll be at the Boulder Java Users Group, giving a presentation on software archeology (which draws from a number of materials on this site).
Some of you might recognize the style of the cartoon in these slides. For both editions of Object-Oriented Analysis and Design with Applications, I commissioned a cartoonist from the UK, Tony Hall. While working on the first edition of the book, I also approached Scott Adams, but at that time he was on his rise to fame and so very politely declined. I've never met Tony - he lives somewhere along the northeast coast of England with a menagerie of animals - although we've communicated over the years by phone, fax, and snail mail. A few years ago, I again commissioned Tony to produce a new set of illustrations for a third edition of OOAD, from which this particular cartoon is taken.
As for this third edition, I've apparently set a record with Addison-Wesley for the most delayed book-under-contract-but-not-yet-finished.
Tuesday, April 13, 2004, posted by @ 5:06 PM
Intellectual Property Rights
My work with the Computer History Museum has offered an interesting scenario that should keep a phalanx of lawyers busy for a while.
By the way, is phalanx of lawyers the proper collective term? We speak of an exultation of doves, a pod of whales, and a gaggle of geese (or is it a gaggle of geeks?). Is it more proper to speak of a legion, a scourge, a shrewdness, an intrusion, a prevarication, or a huddle of lawyers?
Anyway, I cannot at this moment be specific on the system, but the source code to a twenty-year old very seminal and very influential application for the personal computer has fallen into my lap. There's no doubt this is something we want to preserve for posterity; as an historical artifact it's worth keeping, and as an architectural artifact there's much to study. That being said, there's not a a single line of code that's likely a part of any contemporary system, although at the very least the source is still under the legal protection of copyright and/or intellectual property rights of the company for which it was developed. So, there's new legal ground to be broken here, although rather than playing the game of dueling lawyers, we are taking the approach of simply talking to the principals involved and working to Do The Right Thing. This won't be the only time this issue will raise its head, I'm sure, and I already see variations of the theme lurking on the horizon for the Handbook .
Friday, April 9, 2004, posted by @ 11:02 AM
Strachey Lecture At Oxford
I've been invited to give the next Strachey Lecture in Computing Science at the Oxford University Computing Laboratory. I never had the honor of meeting the late Christopher Strachey, but his work was essential to the early days of Rational: among other things, Dr. Strachey (along with Dr. Dana Scott) invented the field of denotational semantics which formed the theoretical basis for formalizing the semantics of Ada and ultimately lead to the creation of DIANA (the Descriptive Intermediate Attributed Notation for Ada) . DIANA was the essential abstraction around which by Rational's early Ada Development Environment was built (and for which we also built a hardware machine that essentially "ran" DIANA).
One of Dr. Strachey's passions was trying to resolve the disconnect between academia and industry. I'm kind of the odd man out in this lecture series, for I'm not from academia, I don't have a doctorate (I'll have to check, but I think I may be the only one from the lecture series), and I'm not a researcher but rather am squarely in industry. I'll be discussing The Limits of Software, a subject that I've been presenting and growing for a the past few years. When I finish my presentation (bringing new meaning to the term on demand), I'll post them on this site.
Wednesday, April 7, 2004, posted by @ 2:56 PM
Software Architecture Glossary
As part of my effort to document the metamodel behind the Handbook , I've assembled a glossary of terms herein.
Tuesday, April 6, 2004, posted by @ 2:34 PM
General Architecture Research
I've posted a number of book, paper, and site references regarding general software architecture topics (remember that if you are visiting the Handbook from the outside, you'll have to sign in first).
I've also posted - but not yet wrapped the words around - a general software architecture metamodel.
Monday, April 5, 2004, posted by @ 10:58 AM
Site Maintenance
I did a little bit of site maintenance on the Handbook today, providing a visual cue (by dimming) the parts of the pages which do not currently contain interesting content but yet can be browsed; I'll extend this user metaphor to the systems pages shortly. This cue is more for me than for users, actually: given that each system has a few dozen parts, this quickly multiples out to a couple of thousand moving parts on the site, each of which can be updated at different times as I advance my research.
There's a metalesson in all this. Adding this feature required the addition of one new method to an existing bean and then some trivial code wrapped around each part in the appropriate JSP page. In all, it took about 20 minutes from idea to deployment. Ah, the joys of having a simple, well-architected site.
Monday, April 5, 2004, posted by @ 9:37 AM
Supercomputing
I've been doing some background research for the scientific systems I'm covering in the Handbook (including systems such as the Earth Weather Simulator). You'll find all the interesting supercomputer systems listed at the Top500 site.
Wednesday, March 31, 2004, posted by @ 11:16 AM
Tools
Following up on my earlier dead tree format riff, I though I'd also mention the development tools I use personally. On the PC, I've got WebSphere Studio Application Developer and all the surrounding Rational tools. On the Macintosh, I develop with Eclipse, Dreamweaver, and CocoaMySQL.
Tuesday, March 30, 2004, posted by @ 9:27 PM
The Importance Of Being Ernest
You wouldn't know it by seeing me in person, but I graduated from the United States Air Force Academy (USAFA) back in 1977. Mike Devlin and Paul Levy, the two founders of Rational, were also in my graduating class (Mike and I were both comp sci majors; Paul and I were roommates).
Speaking of roommates, I also had a roommate by the name of Tony Grady (who was also the best man in my wedding; his last assignment in the Air Force was as test squadron commander for the B2 bomber) and so, naturally, we were the Grady Bunch. Oh, but it gets worse: I also had a roommate whose name was Bert, and since my first name is Ernest, we were dubbed Bert and Ernie.
Fortunately, years of therapy have rescued me from the emotional scars of those days. That, plus late nights of chasing down bugs, I suppose (which is far cheaper then therapy, although to paraphrase Tracy Kidder from The Soul of a New Machine, sometimes one longs to deal with units of time no longer than a season).
Tuesday, March 30, 2004, posted by @ 6:55 AM
Dead Tree Format
I'm a voracious reader, although not just of items pertaining to software but rather covering a wide range of topics from the history of the Middle Ages to quantum physics to political science to a variety of fiction (Paul Theroux, Milan Kundera, and Michael Chabon are among my favorite contemporary authors). In the software space, I'll get into which books and authors are my favorites in some future posting, but it's also the case that I track a couple of dozen professional and trade journals as well as a number of web sites on a weekly basis.
As for professional journals (all of which I retain their dead tree version in my library), I read a number from the ACM (Communications of the ACM, ACM Queue, ACM SIGPLAN Notices, ACM Software Engineering Notes, ACM Transactions on Programming Languages and Systems, and ACM Transactions on Software Engineering and Methodology) and the IEEE (IEEE Computer, IEEE Internet Computing, IEEE Software, IEEE Spectrum, IEEE Transactions on Computers, and IEEE Transactions on Software Engineering). IBM publishes two that I read (IBM Journal of Research and Development and IBM Systems Journal) as does MIT (MIT Technology Review). Rounding out the journals include five others (CORE, MacWorld, Software and Systems Modeling, Software Development, and Wired).
There are twelve other magazines I read weekly or monthly, including Business Week, ECN, Economist, EDN, eWeek, Information Week, Infoworld, MSDN Journal, PC Magazine, PC World, Science, and the Silicon Valley Biz Ink.
Finally, I track seven web sites weekly (developerWorks, ExtremeTech, java.net, MSDN, Slashdot, SourceForge, and the W3C).
And sometimes, when I'm done reading, I sleep.
Wednesday, March 24, 2004, posted by @ 3:34 PM
Cafe Scientifique
Last night, I spoke at Denver's local Cafe Scientifique on the Limits of Software in which I discussed what separates vision from execution in our industry. The Cafe is a phenomenon that started in Europe and is based on the French Cafe Philosophique. This is distinctly not a sofware-only venue, for of the 70 or so people who attended there was in the audience a charming couple in their late 60's who simply love to learn, a highway construction engineer, a microbiologist, a theoretical physicist, a researcher in nanotechnology, and several artists. I enjoy talking to fellow geeks, but this event was a huge amount of fun for me. As I note on this site, software is largely invisible to most of the world and thus although the general public encounters software every day, the experience is typically binary: it is either hidden or in your face (as noted by the many times people expressed frustrations with the PCs). Among other things, I talked about the amount of software produced in the world, the things that make it difficult to produce software, and the trajectory of our industry. Most of the time we spent in a lively discussion that covered such topics as artificial intelligence, the death of Moore's law, and the moral and ethical implications of software, such as software for voting systems, facial recognition, and genomic.
Saturday, March 13, 2004, posted by @ 3:54 PM
More Hairy Mathematics
While conducting research for the missile guidance system mentioned in my previous posting, I came across a wealth of information from the American Institute of Aeronautics and Astronautics. Paul Zarchan at the MIT Lincoln Laboratory has written the seminal text on the topic, Tactical and Strategic Missile Guidance. I'm currently pouring through that book, and have on order some other books from AIAA regarding the Global Positioning System (GPS) and aircraft/weapons simulations.
Thursday, March 4, 2004, posted by @ 11:47 PM
Hairy Mathematics
It's raining here in Maui and the whales are all hiding, so I've been poking around the architecture of three unrelated systems: mobile phones, SETI@home, and a to-be-named missile guidance system. One thread that weaves through the warp and woof of these particular systems is that of some very hairy mathematics. Whereas the typical enterprise system is mathematically sparse - the naughty bits of such systems involve mostly functional (and highly volatile) business rules together with a pile of semantically-connected objects - these other systems require some finely-tuned, computationally expensive algorithms. In the case of mobile phones, the Viterbia algorithm is a Markov model typically employed by a DSP inside the phone to remove noise. SETI@home is a classic example of a massively distributed system (for analyzing radio telescope data), using a Fast Fourier Transform (FFT) to identify the frequency spectrum of a noisy signal. Finally, in the case of this missile guidance system, a Kalman filter is used to direct its flight path.
In all these cases, tuning these algorithms is plain hard work that requires some deep mathematical analysis as well some very clever programming.
Saturday, February 28, 2004, posted by @ 11:00 AM
Call Me Ishmael
I'm back from Boston and am about to catch a plane for another trip, although this one is only for fun: I just celebrated the 31st anniversary of my 18th birthday and so as I typically do this time of the year will travel to Maui to do some whale watching. Speaking of whales, there's of course a software element to all this: among other groups, WhaleNet tracks a variety of marine mammals each year. The principal is simple, but ultimately requires the services of a satellite from Argos in communication with a tag on the mammal itself.
Software is indeed in the interstitial spaces of the world. And no, I don't intend to deduct this trip as a business expense, even though I'll be thinking about software while lying on a beach.
Monday, February 23, 2004, posted by @ 9:50 PM
Intermezzo
I've landed back home for 24 hours - just returned from LA, off to Boston tomorrow morning - so today was primarily a dig-myself-out-of-the-email-avalanch kind of day. I've been reading some backstories on the Spirit to better arm me for the future dig on that particular system. The last week, in my spare time, I slogged through revisions of the illustrations to the UML User Guide in order to update it to UML version 2.0. That book I'll finish far ahead of this one, and at any rate, I need to spin myself up to the latest 2.0 details. And yes, with great tenderness and compassion offered to my long-suffering editor at Addison-Wesley, I will get the User Guide out the door this year. The third edition of Object-Oriented Analysis and Design is still something I've not forgotten, although, like the late Douglas Adams, "I love deadlines. I especially like the whooshing sound they make as they fly by."
Friday, February 13, 2004, posted by @ 4:50 PM
Geek Eye For The Cobol Guy
Not much to report publically today; in the time I've had for this project since my last posting, I've been heads down uncovering various papers on beauty and elegance (in software, that is). Based on what I've learned, I'm thinking of pitching to Bravo an idea for a new reality series.
Thursday, February 12, 2004, posted by @ 11:49 AM
RSS Feed Operational
Approximately 50 lines of Java all wrapped up nicely in a bean, and the RSS feed for this blog is now working. Since I've validated the feed through FeedValidator, I've changed the original XML icon to the left of the Archives (Current) menu to a more appropriate image. Enjoy!
Thursday, February 12, 2004, posted by @ 8:12 AM
Blog Access
I've decided to make this blog publically accessible. As I worked through the use cases of the RSS feed, I realized it was futile to put the blog itself behind this site's registration mechanism, since linking to the feed made a summary of the blog's content public anyway.
There's a sample feed working now, in case anyone would like to try it out; I'm refactoring what works into a more properly-structured bean.
Wednesday, February 11, 2004, posted by @ 2:27 PM
Site Maintenance
Ok, the uploading of large files is now fixed. I had built a bean for this site that permits me to upload files - that's how I push images and other artifacts to the site while editing it in place in a Wikiweb-ish manner rather than having to go back to my Eclipse/Dreamweaver development environment every time - but it failed silently on really large files. If you'd previously tried to download my EclipseCon presentation you would have found yourself with a corrupted zip file as one side-effect of this bug, but things should be working now.
You'll notice also the little XML icon to the left of the Archives (Current) menu. At this moment, it doesn't do the Right Thing, but it's the placeholder for my providing an RSS feed for this blog. Adding this facility to the site, even though I'm hand-coding it, turns out to be blindly simple. I'm not done yet - I've worked out the UI and I'm polishing the bean that does all the heavy lifting - but when it's finished, I'll let you know here.
Tuesday, February 10, 2004, posted by @ 9:21 PM
Software Archeology
As I promised in the previous posting, I've completed an exposition of the process I'm using to conduct the archeological dig for each system in the Handbook.
Monday, February 9, 2004, posted by @ 7:35 PM
Random Musings
I'm back from EclipseCon, which was a smashing success. The organizers had needed 300 to break even, but there were over 600 in attendance (only 20ish% IBMers, thus showing that Eclipse as an independent entity does have legs).
I'm due to visit a gaming company next week - er, correction, a "game" company..."gaming" is all about gambling, and "game" deals with the classic first person shooter/adventure/simulation/flight/etc genre. Every domain has its own lingo, and when in Rome...
Anyway, it's been a productive few days. I've tracked down the chief architect for JPL's Spirit, listened to an outstanding presentation on the Eclipse development process, and just had an email fall in my lap from Tim O'Reilly who through Andy Hertzfeld and then Bill Atkinson has tracked down the source code to MacPaint, a perfect addition to the Computer History Museum project on preserving classic software. I'll be conducting a BoF at the upcoming Rational User Conference on archeological digs. I already have the source code to Eclipse, Doom, and BillG's original Basic interpreter. so this would be a nice addition for us to explore.
Tonight I have some maintenance to perform on this site; uploading large files is broken - I made some wrong assumptions about the structure of PowerPoint files - and I want to make explicit the state of each system under investigation. I've already worked through a common scenario for conducting archeological digs (which I'll get around to posting in the architecture section soon) and as I push forward on a few of these digs, the essential phases of all digs are becoming clearer.
Friday, January 30, 2004, posted by @ 12:26 AM
RSS Feed
I've had a few requests to provide an RSS feed for my blog. Given that I chose to write my own blogging mechanism rather than using something like Blogger, this facility doesn't come for free, but rather is something I have to create. In poking around the latest RSS spec and various forums, it appear to be a problem that's only a bean away. I've added this story to my list of desired features, and so will plan to push it out as part of the ongoing evolution of this site. (and will announce its existence when it's in place).
I'm off to EclipseCon shortly, so expect radio silence on this site for a bit (and when I get back, I get to try out the archiving mechanism I created for this blog, which in theory will roll everything over at the end of each month; ain't technology great?).
Thursday, January 29, 2004, posted by @ 9:36 PM
History Of Development Environments (Final)
This week started out so gently and so full of promise, but very quickly my calendar wrenched itself from my Palm and ran careening about the office, bashing into my most well-intentioned plans, knocking some of them ajar and others totally senseless. My calendar now sits whimpering in a dark corner beneath some dusty printouts. Some weeks you get up and it's hardly worth gnawing through the leather straps.
Nonetheless, one bit of tangible work I did manage to wrestle to the ground was my presentation for EclipseCon, on the history of development environments. I could have easily spent several more days on this subject, but part of making progress on this broad project is learning when to say it's good enough. I'm sure I left out some historical events of interest; I know I could have done a better job at illuminating the human stories behind these works, such as the tale of Alan Cooper (on Tripod which became Ruby which in turn became Visual Basic), Warren Teitelman, Alan Kay and Adele Goldberg (on Smalltalk which begat Squeak), Tony Wasserman, and oh so many others.
Wednesday, January 28, 2004, posted by @ 8:52 AM
History Of Development Environments (Revisited)
Despised googling the subject and hunting around all the usual corners of the ACM and IEEE digital libraries, I've yet to find any reasonable compilation of the history of development environments; I find lots of short threads, but nothing that steps back and looks at the general epochs and trends.
However, forming the warp and woof of those threads into a whole cloth, I come to the conclusion that there have been about five identifiable generations of development environments: early tools (from 1945 - 1960), command line environments (1960 - 1980), integrated development environments (1980 - 2000), extended development environments (2000 - 2004) - this is the current age - and all morphing to collaborative development environments. In some ways, it's surprising that environments as a whole are not as far along as is possible; at the same time, I certainly expect development environments to continue to evolve in reaction to and to lead advances in languages, platforms, and processes.
Tuesday, January 27, 2004, posted by @ 3:19 PM
History Of Development Environments
Today I'm spending some time digging into the history of development environments; I'm doing this research to prepare for my EclipseCon keynote as well to serve as an element of my archeological dig for Eclipse itself, one of the systems under consideration in the Handbook.
Why is the history of a system relevant to its architecture? Every architecture, be it intentional or accidental, is a product of its time and the forces at play at that particular moment in time are in turn shaped by the systems that preceded it. I would contend that there are few truly novel software architectures. Rather, as with every engineering discipline, new systems or modified ones are build upon the shoulders and ashes of previous ones. As Henry Petroski observes in his many delightful books, this is how industrial engineering advances - and so it is with software.
Monday, January 26, 2004, posted by @ 10:42 AM
SLOC
I'm off to speak at XP Denver this evening; one of the topics I'll present is the cumulative SLOC estimates I've made in this site's system page. I've made contact with Stephen Hendrick of IDC, upon whose study of the worldwide developer market I've based some of my assumptions. Reality is, there's scant hard data that covers this space, and so I'll continue to poke around here to validate some of my assumptions (such as the average SLOC/developer/year).
Friday, January 23, 2004, posted by @ 7:50 PM
Open For Business
I've been working with about a 10% duty cycle the past two months to build this site: the holidays intervened and work filled my days, but the site is now sufficiently stable for me to begin using it to collect artifacts in earnest. Opening the hood a bit, I first modeled the site and its contents using Rational XDE. I used Eclipse to build and debug the beans (there are six in all), Dreamweaver to develop the pages (there are 18 different pages), and CocoaMySQL to lash together the database (it's a simple one, used mainly for account authorization; most of the state of this site is in HTML, XML, and PDF files). All this madness is running on an Apple XServe. I'm connected to the world via a T1 with an industrial-strength firewall appliance between me and the naked world, and so hopefully I'll have sufficient capacity and defenses for a while. I intentionally put things on the web (but with the bulk of the site behind an authorization mechanism) because I expect to be collecting artifacts from around the world, and in this manner I can bring my work with me wherever I go.
There are three fundamental mechanisms that shape the architecture of this site: an authorization mechanism, mechanisms for navigating about the artifacts therein, and a Wiki-like mechanism for editing the contents of the site in place. Authorization is as one would expect, with special care taken to protect against attacks against mangling URLs. Coming up with the proper navigational mechanism was easy, largely because I started with a model of a model of architectural artifacts. The Wiki-like mechanism took the most time to get right; basically, I wanted to edit all content in place (that was easy), provide some editing toolbars to make my life easier (also not hard, just tedious), and then also to be able to manage uploading images and other artifacts used on the site (that was a little tricky, but in the end pretty slick). Oh, there's also the blog: I started to use Blogger but eventually threw that away and wrote my own blogger code: it was clumsy having one mechanism for blogging and another for editing other content in the site, plus these pages are sufficiently complex that the complexity of pushing these pages as a template over the Blogger greatly outweighed any convenience that Blogger provided. I lose RSS publishing, but that's not a critical feature that I care out, anyway. Some things still remain: search is not yet active (I simply haven't gotten around to it, but will once the lack of it becomes sufficiently painful to me) and I'd like to add integral spelling check to the editing toolbar, but otherwise, it's passed the threshold of usability for research. I'll start opening the site up to a few select folks, but it won't pass the threshold of usability for the masses until I've completed a few digs.
Thanks go to Grant Larsen who was my sounding board for the UML models and especially to Jim Conallen who was my geographically distributed pair programmer.
Friday, January 23, 2004, posted by @ 3:55 PM
Spirit
One of the systems on my list for investigation is an instance of any number of autonomous vehicles for space exploration. Having a military background, a lot of my early work was in space and missile systems. It was that early experience that really led me to appreciate the issues of large scale, distributed, concurrent, and secure systems - and that was in the 80s, a time when the DoD was perhaps the first to be deeply immersed in such domains. I'd first met with the folks at the Jet Propulsion Laboratory a few years ago, at which time I had some discussions with various teams working on some deep space vehicles. At the time, I thought it would be interesting to deconstruct the software for the Pathfinder but simply did not have the time to do so. Well, here we are in the midst of a renaissance of exploration with the Spirit rover on the Martian ground and - as I write this blog - another one due to land shortly. A few days ago, I made connection with JPL to set up a visit...and later that very day news broke of Spirit's anomaly. Needless to say, the Spirit's architects were were a wee bit busy: imagine trying to debug your computer across 35 million miles with a connection of about 120BPS. We decided to let the dust settle, and reschedule a visit for some future date.
Wednesday, January 21, 2004, posted by @ 10:57 AM
Eclipse
I'm keynoting EclipseCon in Anaheim in a couple of weeks, at which I'll be talking about the evolution of development tools over time. I'm in the midst of researching the history of tools - from command line tools to integrated development environments (IDEs) to extended development environments (XDEs) to collaborative development environments (CDEs). IDEs are a staple of any development shop, although Emacs certainly still has an incredible amount of traction around the world. There are some interesting trends in this space that I'll explore, as the importance of development as a team sport and the opportunities of model-driven development and asset-based development gain ground. Grant Larsen has been studying Eclipse's architecture, both through a review of available documents as well as by reverse engineering the entire Eclipse source code and then picking through the pieces. There are some interesting lessons learned in how one conducts an archeological dig, but I'll leave that for a later exposition as well after we have a few more under our belt. What I can say at this point is that a) Eclipse does have an architecture but b) it's pretty much locked up in the minds of its creators, except for some very high views and some very detailed aspects which have been articulated.
I'll be speaking at XP Denver this coming Monday and will talk about a few things we've learned thus far.
Tuesday, January 20, 2004, posted by @ 12:25 AM
Activities
Thus far, much of my time with this project has been divided between two activities: first, selecting a collection of systems for study, deciding which artifacts should be collected for each of them, and then defining a process for conducing my archeological digs; second, building this web site to collect those artifacts for study.
Under the first topic, my choice of systems here has paralleled an effort I started with the Computer History Museum to preserve classic software systems - although that's a topic for a much longer discussion. For the Handbook, I'm trying to assemble a set of systems that will be fairly comprehensive in terms of problem domains, architectural styles, development cultures, and geography of origin. My premise is that there exists only a relatively small set of distinct architectural patterns, although each instance is clearly shaped by the engineering and business forces that surround it. Four wicked problems lurk here: no one has ever really cataloged and then named this set of architectures, within each domain we find projects that reinvent the same architectures again and again, developers within a given domain often have no knowledge of the architectures found in other domains, and finally, it's not clear how we can best represent a diverse set of architectures in a common fashion that permits comparison across domains. I research and write so that I can learn, and at the very least, I'll be chipping away at each of these four problems.
As for the second topic, the construction of this site, I decided to create it for a couple of reasons. First, as I reflect on the way in which I carried out the research for my previous books, it's clear that I have a much more challenging problem for this effort, largely because the information I need to carry out any one archeological dig is for the most part locked in the heads of their respective developers and/or found in tantalizing clues left scattered in a myriad of unrelated documents - multiply that scenario by two orders of magnitude, and you get an idea of the amount of information I need to collect over time. The past several years, Alan Brown and I have given thought to the construction of collaborative development environments (we published a paper on the topic in Advances in Computers, vol. 59), and so it seemed obvious to apply those ideas to this research problem, hence this site. Second, I genuinely enjoy programming - you should never trust a methodologist who does not cut code, IMHO - and so building this site gave me the opportunity to keep up my skills.
Monday, January 19, 2004, posted by @ 10:58 AM
Welcome
In November 2002, I began a blog on software engineering; two weeks later, IBM announced its intent to acquire Rational, a deal which was finally consummated in March 2003. Needless to say, I was swept up by those events and so my original blog lay fallow. Life has finally reached a reasonable point of stability and thus I've been able to turn my attention back to this effort, albeit with a slightly different focus.
For much of my professional career, I've had the opportunity to work with a multitude of software-intensive projects from a diverse set of domains. Each project has its own unique personality - a particular development culture, certain engineering forces that weigh upon the team, the business and economic context - but there are always some common themes that cut across these specific projects and domains. Some of these common elements have been codified by our industry in the form of programming languages, protocols, and frameworks as well as in best practices for development, yet many of these common elements represent patterns of design which typically live only in the tribal memory of individuals or specific projects. The patterns movement, perhaps as best embodied by the Hillside Group, has worked to make many of these patterns explicit; indeed, I consider patterns to be one of the most important advances in software engineering over the past decade.
As an architect and architectural mentor for a number of systems around the world, I have always been a student of software architecture. Every software-intensive system has an architecture, some of which are intentional but most of which are accidental. In any case, the best architectures are grown over time and, as Christopher Alexander observes, the best architectures are full of patterns. Inspired by the work of Philippe Kruchten and Bruce Anderson, I decided to turn my attention to assembling a set of architectural patterns that collectively represent a large spectrum of software-intensive systems. This site serves as the place where I will record my archeological digs; this blog, rather than addressing general software engineering, will serve as a record of those digs as well as my random observations on the systems under study.
|
Blog