Report from OOPSLA
We’re into our third day here at OOPSLA. On Monday, Jack Greenfield, Steve Cook and I delivered our full-day tutorial as I described in my last posting. I think it was received well by those who attended – based on chats we had with those who shared the day with us. Of course, we won’t really be able to tell until we see the evaluation forms.
We had to explain to those that attended that we were performing something of an experiment on them. Several weeks ago we had submitted a day’s worth of slides to the organizers, which were duly duplicated and ready for the attendees when they arrived. But we took a risk to completely ignore that deck, which was a synopsis of our book on Software Factories, and instead spend the whole day working through an end-to-end scenario showing how four variations of an application could be specified and built using assets provided by a Software Factory. We took this risky step based on some feedback we received at the Strategic Architects Forum in Redmond a couple of weeks ago. Most people we spoke to there were interested in the ideas, some very much so, but many people told us that they found the concepts a little abstract, and needed many more examples of DSLs, customized guidance and custom content.
So that’s what we did. It involved us in a long week of rebuilding a deck and building applications (ably assisted by Michael Lehman). We took the famous Pet Shop application (the .Net version which can be downloaded from msdn), and defined two organizations building e-commerce pet shop applications: PetShoppe, a small business with modest requirements, and PetCluCo, a larger organization with more sophisticated requirements. We first asked the audience to suspend belief and imagine a Software Factory from which these applications could be built and then modified when requirements changed, or in the case of PetClubCo, the business needs changed.
We then showed a number of tools, based on DSLs, that could be used to configure business capabilities and system requirements, and produce implementations from these, first in the case of PetShoppe in a largely manual coding style, and second, in the case of PetCluCo, using a powerful set of DSL based tools to allow the developer to be more efficient, and do less rote programming tasks. Only at the end of the day, did we show how the Software Factory assets were designed and created. I’ll be writing a more detailed summary of the tutorial in a few days time, and I’ll post here when it’s ready.
Some of these tools exist and will ship with Visual Studio 2005 Team System. Others could be built using the framework and tools we use in Microsoft to define DSLs and build tools that support them. We also showed a demo of these tools (building a simple Web page transition design tool – Harry Pierson has posted a screen shot of the simple tool we built in the demo). This is the framework and tool kit we announced yesterday at OOPSLA as described in various press coverage (the ServerSide, CRN, and Computerworld). We’ll be posting a lot more information about this framework and tools in the next few days. Stuart Kent has set the ball rolling in his blog. We hope that many of our customers and partners will build the tools we showed in the tutorial as mock-ups.
Unfortunately, yesterday’s announcement of what we’re doing with DSL building tools and Software Factories was somewhat marred by some unintentional clumsiness on our part at OOPSLA. The description of the availability of the technology and the things we’re working on came across as a product announcement – an unwelcome thing at OOPSLA conferences. Several people at the conference expressed their disgust in various obvious ways (including Alan Kay who chose to lampoon Microsoft about this in remarks sprinkled through his Turing Award keynote). All I can say is that we’re sorry this happened in this way. We’ll learn from this and make sure we respect OOPSLA practices in the future.
Right now I’m sitting at the back of the GPCE keynote in which Jack is giving the Software Factory talk. I’ll report on feedback later.