Verticalized tools in the
near term?"> So are we in the near term going to see anything like "verticalized" tools for vertical markets? Yeah, I think you will. And through the efforts of Grant Larsen, who is our patterns czar for the software group, driving a lot of the interesting stuff in that space, what we realized, especially with IBM aligning more and more of its field to specific verticals, is that there is such a domain-specific language and culture in those verticals that you can get middleware, which covers a lot of horizontal stuff. But now those verticals are where the action is happening. Because, frankly, J2EE [Java 2 Enterprise Edition] and .Net are still too complex for the average developer. So, yes, we see the growth of those particular vertical patterns in all those places.Do you expect to deliver that?Its certainly the plan of record for what were doing in the pattern space. In fact, if you go to the developerWorks site, the intent with the plan of record is to expose a number of those patterns because theyre there for the harvesting. IBM already has precedence in things like the Insurance Application Architecture, which is used by some 85 percent of that community. Frankly, IBM failed in a project called San Francisco some years ago. And I think the primary reason they failed is A) they over-engineered it; and B) they produced those frameworks by creating them from whole cloth as opposed to harvesting. And our experience thus far is the best architectural patterns are extracted from the ashes of existing systems. And thats the effort that Grant has been leading, to do that kind of extraction. And the MDA piece of it fits in as well, because then MDA represents the automation part of the patterns and now this represents the content piece of this one. You just did a talk on software archeology. What is that all about? There are three major points that I made. The first is especially in todays world of building consistently of all these systems, rarely do we start green field, but theres a tremendous amount of activity to look at existing systems and adapt them, reuse pieces of them into what we have. And oftentimes, too, people are parachuted into a system saying go fix this and not having a lot of context. So there is emerging a body of knowledge about what it means to do an archeological dig, what processes are necessary for us to be launched into a system and intentionally seek out a reconstruction of its design. Because even though we may have the code, there is entropy at play. I have the design here, the codes here at this end, and theres a loss of information as I move it to code. So what can we do process-wise and tool-wise to re-create that kind of stuff. We know today sort of some macro processes how to do that. And thats what I described in my talk. There are some people who have looked at micro processes. Theres a great book called "Software Exorcism," which sort of looks at the debugging and investigation process. So good stuff is happening in that space. As we move to those kind of skills, we recognize theres still one gap, which we as an industry dont have a lot of tools to help us do those digs. As I showed in todays talk, we reverse-engineered the architecture of Eclipse. And it was easy in the sense that we had all the source code for it. Because in many cases you dont have all the source code. And yet there arent a lot of design documents for Eclipse that lie around. Most enriching design information is in tribal memoryin the heads of people who actually wrote it. And they havent extracted it. So what we found in this process is we can reverse-engineer it, we can build some models, but extracting the patterns from those models is very, very hard and it requires human intervention. I think that there are opportunities for some degree of automation to identify patterns from that cacophony of classes. And thats an area of research that the industry needs to spend some focus on. The second point I made was actually mentioning the handbook project I talked about. My intent is to look at 100 different systems around the world and codify their architectures, because no such reference exists for software engineers these days. Architects have to learn by doing, and Im trying to provide a reference for them. So were looking at lots of different systems. And the third point I made was an effort we have with the Computer History Museum to preserve classic software. So weve intentionally gone after a variety of seminal systems that, frankly, our industry has given much to the world; it would be sad if we lost a lot of those artifacts. So the intent is to capture the source code, capture the artifacts around it, interview the people who did it, so itll be preserved for future generations. I actually went into some depth about MacPaint. Because the source code to MacPaint fell into my lap about a month ago. Tim OReilly has been involved in this effort; he had been talking to Andy Hertzfeld and Bill Atkinson and he mentioned it to them, and Bill and Andy got in touch with me and said: "Weve got the code." And actually theres an interesting back story about how they got it, because it had been sitting in Bills garage on Lisa disks. And he didnt have a Lisa around, but the end of the story is Andy was able to deliver me a CD-ROM with the source code for MacPaint. And about two or three weeks ago I did an interview with both Andy and Bill, and we have a video interview of this stuff. So its very cool. And we want to do this for many other systems. So thats a real instance of an archeological dig. I have in my office the original source code to the Multics kernel. We have one of Bill Gates original tapes for his first BASIC program. Were looking at a whole bunch of stuff like that. Dan Bricklin weve been in touch with. Wed like to get the source code to VisiCalc. Next Page: Simplifying Rationals tool set.