Hi, I am Gregor Hohpe, co-author of the book Enterprise Integration Patterns. I work on and write about asynchronous messaging systems, distributed architectures, and all sorts of enterprise
computing and architecture topics.
Find my posts on IT strategy, enterprise architecture, and digital transformation at ArchitectElevator.com.
Technical conferences are great. You get to network with your buddies and during the sessions you finally have time to get some actual work done! No interruptions like phone calls, e-mail etc. Some of my conference weeks are actually the most productive.
This is my first time at the Patterns and Practices Summit and I like it quite a bit. The show sports some celebrities like Alan Cooper, Blake Stone (ex Borland, now Microsoft), and Ward Cunningham and a nice line-up of people who have a lot to say about Microsoft technology: Jim Newkirk, David Trowbridge, Rocky, Ron Jacobs, Ted Neward. The event is not huge, so attendees get to hang out with speakers quite a bit. I think with a little more marketing this show could become the equivalent of TheServerSide Symposium for the .Net world. Unfortunately, there is much less going on in the open source world for .Net but that is changing as well. Maybe it would be worthwhile to invite Erik to talk about Neo or Rod to talk about Spring.Net.
My favorite feature of the conference is that each attendee receives a USB Flash drive with all the presentation material on it.
Alan Cooper gave one of his equally insightful and controversial talks on how to end the dreaded Death March. He reminds us to focus on user-centric design and to remember that in the software world "Users do not equal customers". For example, many of us use MS Office but very few actually purchased an individual copy at the store. Alan also distinguishes very clearly between Design Engineers, who want to do it right, and Programmers, who want to ship. Death March often ensues because management puts the technical people under pressure to solve problems that are really management problems. Subsequently, the team falls into the "Efficiency vs. Effectiveness trap": They try to build as many features as possible forgetting that features really don't matter. What matters is satisfaction.
My favorite quote: "It takes technical and management people time to find the right level of communication where they can understand each other. Sort of like two modems going "beeeeep, beep, beep" until they found a compatible bit rate".
Billy gave a nice talk on smart client development and how to use a more declarative programming style to deal with items such as validation. .Net and Visual Studio allow the creation of Extender Providers, controls that can extend properties of other controls. Once the extender control is placed on a form, other controls on the same form show a new property in the property window. Some of the VB case statements look a little scary but using these controls has a nice aspect-like feel to it.
One might wonder whether there is much more left to be said on patterns. If there is one to prove that wrong, it is Ward. Ward has been very active in creating PatternShare, a forum for patterns. It is a little more structured than a Wiki but allows third party contributions. Microsoft preloaded the forum with content from the GoF, Martin's book, the Microsoft PnP books, Eric's book and our book. A big bonus: all the content is available under the Creative Commons license, pioneered by Larry Lessig, not some obscure Microsoft EULA.
Ted hosted a very interactive session on design patterns. About half the audience declared themselves as regular pattern users so it was interesting to get feedback on the accessibility (or lack thereof) of design patterns.
An interesting question came up regarding the Service Activator. Isn't a Service Activator just a special form of an Adapter? I would be inclined to say that the overall intent shares some similarities (e.g. "make A look like B") but the context and the scope of the problem are quite different. The GoF Adapter only translates from one interface of a class to a different one. A Service Activator in contrast has to deal with object-document mapping, asynchrony, remote protocols etc. If you define an Adapter broadly enough to cover all these scenarios you don't have much left to say about the solution. Therefore in my opinion it helps to draw a little more context around the pattern so we can provide more concrete guidance with the solution and the resulting context.
The next interesting question centered on patterns becoming part of the language, for example a DataSet being the incarnation of a Data Transfer Object. I pointed out that the DataSet is not actually a language construct but part of the .Net library and that it is fairly common for a library to implement very common patterns. This initiated another comment from the audience that delegates are in fact a language construct and implement for example the Publish-Subscribe Pattern. That question triggered another thought, namely whether patterns depend on the programming language. The consensus was that a pattern should not depend too much on the programming language, and if it did it would more likely be called an idiom. Patterns do, however, depend on the underlying programming model. That's why patterns for object-oriented applications are different from patterns for asynchronous messaging. Delegates are an interesting case because they are part of the C# language but they have little to do with object-orientation. They are much more aligned with the pipes-and-filters style that underlies most of the patterns in our book. So it is interesting to see that even within one language different programming models and therefore different patterns can emerge.
Mike Kropp, who is running the PAG group, pointed at the apparent lack of higher level patterns that let us start with business requirements and trace them through to an implementation. Tomorrow, David Trowbridge will demonstrate some of that with the Global Bank example the PAG group has been creating (with some help from ThoughtWorks). I particularly like the notion of a "narrator application" that visualizes how all the pieces work together. Now if that image was only generated dynamically :-)
Another cool quote from Ted Neward: If you publish an interface you can change it as long as you don't violate the "2 cubicle rule". If the users of your interface are no more than 2 cubes away you can simple yell "foo changed". This underlines the fact that the rules in distributed systems development are very dependent on the organizational structure of the development team: if I have control over all pieces (e.g. because one team is building all pieces of the application), I don't need a whole lot of loose coupling.
Now I am off to SD West. Attendee numbers at SD have been growing nicely with SD West 2005 clocking in at over 1100 attendees. Next week it's back to real client work, messing around with .asmx Web services, Soap Extension Reflectors, WS-Addressing, WSDL and friends.
Gregor is a cloud architect and author. He is a frequent speaker on asynchronous messaging,
IT strategy, and cloud.