Hi my name is Ryan Slobojan I am here with Erich Gamma. Erich, can you tell us a little bit about the Jazz project?

Sure, Jazz is a new technology I have built, we have started on that three years ago, it's really based on lots of experience we gained in Eclipse. In Eclipse we learned about Agile practices, distributed development, we learnt a lot about how good is to have powerful tools for coding for development. But we also learned that there are areas where there is friction and, particularly when you want to work in a team, there are places where I don't think you will get the same level of support as you get from the IDE.

And that's why we started to really look into how could the new generation of team tools look like, they are built on a common platform, the platform of course again it's the same spirit as Eclipse, should become an extensible platform, and multiple tools can build on top of it and then also can be integrated. Seamless integration -- the same as you have on the desktop, we'd like to have seamless integration for team tools. So that's how we started, and then we noticed quickly that if you want to get this tight integration level, this seamless integration, then we found we should really build... initial focus on the bug-tracking system to track your work, we need a build system to track our continuous build, and we also need to build a new source code control system which enables us to do this kind of component-based development, and highly collaborative work in code, make it easy to flow changes and make this kind of parallel development very easy.

That's how we started, and that's the Jazz technology platform. On top of this platform what you will see coming out in the future is different products that will leverage this technology and package it, so that you will have this full family of products which can cover the application lifecycle. But our initial focus always was more coding, building, work tracking, bug tracking, source control, but you will see more stuff grow over time.

And when do you expect the initial release of the Jazz platform to be and what capabilities are you planning to have in that release?

As I said Jazz is a technology platform and products build on top of it. We have actually made Jazz available to the community since last June, that's the beta 1, we made beta 2 available in December and beta 3 will be out April 4th, which means it's then very close to 1.0 which will be end of June.

And this will be in a product which we call Rational Team Concert, which of course the concert emphasizes how teams collaborate together, and it really targets Agile teams that want to work in a highly transparent, iterative way and it will have packaged in the source code control system, the build system, the bug-tracking system, but in addition to that also connections to existing technology like for source control, there will be a bridge to Subversion in there so you can gradually start adopting the technology, right - continue on Subversion but use the bug tracking, use the planning support we have and then the build system. And we also have different connectors then, of course, to Rational technology like ClearCase and ClearQuest. So it is really near and we are right now in the finishing phases to make the ship happen. The release is going to be at the end of June. Software engineering calendar, right? Software engineering calendar is always at the end of the day. If you say first quarter it means end of first quarter. The release will be end of June.

One of the things that characterizes the Eclipse project versus other software projects is that it tends to stick to a concrete deadline as opposed to having releases in a haphazard fashion. Why is that and how has that driven Eclipse development?

There are several reasons. First of all we know we have people that build on top of Eclipse, right? Eclipse is a platform, and this requires some level of predictability. And what is the easiest for us if you have some regular rhythm then no one has to remember because they just know the rhythm. So that's how we got into the one year releases, it's highly predictable. Once a year, they get a new Eclipse release and we plan and arrange this that we can ship at the end of this year. And we are really strict, right? We don't want to slip, we'd rather throw out features, because the old saying is valid: users will always remember when you slipped but they can't remember all the features you have thrown out.

That is very important to us and since about seven or eight years we have June, we ship, and we were kind of proud now that we could hold this date. And it's a credit to the team of course that they got their acts together. And June is a date, I explained this in my talk previously, June is just a date, if you look at all the constraints: you have to ship once a year right, you don't finish it around Christmas, you don't want to ship after summer, during summer because of summer vacations, so we really ship just before summer vacations, June is the ideal date for us and that's what we always align as, and you get used to that quickly. And the other rule is, you know, if you never slip you never get used to it, so that's why.

That makes sense. Staying on the Eclipse track, how has Eclipse developed the ecosystem which exists around it? There seems to be a very large ecosystem of plugins and projects and implementers such as Aptana or Adobe who have built things on top of the Eclipse IDE. Why do you think that is?

Of course, this has exceeded all our wildest dreams what has happened here. I think we have done several things... we have done something right. The first thing was, you know, we had this idea that we build, we design it for extensibility from the ground up. Extensibility means also scalability, so be very careful about what measures you need to get a scalable system, where you can have, really, thousands of plugins on top of it.

So that's why we have this plugin model that we have with the lazy loading, with declarative extension points that drag in the real code as you really need it. I think that was an important step, the component model. The other one, also, is that we made it easy for you to develop components, so we not only make the component model available with plugin extension points, we also gave you powerful tools to do that. Part of that is, of course, the Java Development Tools which come right with it, but in addition to the Java Development Tools there is also the Plugin Development Tools which allow you to extend Eclipse, they allow you to make it easy to define and maintain all these relationship dependencies between plugins.

I think that is number two, number three is that you will disrupt community growth if you continuously… this the API point, right? We focus on stable APIs, so we understood it was a commitment up front and we maintained our APIs, so we tried to really avoid breaking our community. That was number three... Wow, I can go on! So number four is really I guess we had this open channel established, right? We have active newsgroups there with active developers participation, right? If you want to get different questions answered you will get the answers from our developers, and this makes the community interesting. Number six I think is the continuous progress; you grow a community by showing continuous progress, because that's what they want to see.

They want to see that they listen to feedback and that again gives you this nice growth path. So continuous progress which we do by our milestone progress. It all comes together, right? And I think... And then of course they're writing all their own interesting... People have started to contribute plugins to it, others have talked about it and that's how it has grown. And, yeah - will be exciting! Once a year we have this EclipseCon conference that is always exciting to get there and see what is new, it's because right now I can not track anymore, right now it is also... Number six, the foundation.

Eclipse is not controlled by a single company. There is the Eclipse Foundation which is an independent company, which has a well-defined governance structure, how a new project comes in and so on. This independence is yet another important factor. IBM started Eclipse, but at some point it was decided, to really open it up and get everybody to join it, it has to be independent. I think this was a strategic decision from IBM which was I think a very good move, because this has opened the doors for competitors to get on Eclipse and to also ship products on top of it, which you have seen - BEA has shipped products on top of Eclipse, and this wouldn't have been possible without this move of independencizing. So many things come together, right? It's not a single thing -- technology, community, independence, that all come together and make this momentum we have right now.

If I recall correctly, yourself and Kent Beck created JUnit?

It's kind of interesting, the step from Eclipse, powerful architecture extension to JUnit, really something very small. It's really the other end of the spectrum but impact-wise it's also interesting, right? Now actually Kent had a unit-testing framework, SUnit, Smalltalk unit-testing framework, whatever it was. And he was doing some consulting for two years in Zurich and we always enjoyed programming together, and then he started to show me that and convince me more and more... "See I put System.out.println() in my code to test my thing - wouldn't it be nice if I don't have to visually look at?" Yes it would be nice but of course I don't want to make it more complex than putting a System.out.println() in my code, and that's basically what he had started to show me was that SUnit has this characteristic: it's very simple, it's not a testing framework with all kind of complex stuff, it's very very simple.

So then it happened that we were flying to OOPSLA together, this was, I don't know... Wow! Ten years ago, something like that? And then we decided, "why don't we program together?" He has SUnit in mind, how it was, and Kent at that point wasn't an experienced Java programmer, I have done some Java programming, and then we pairwise-programmed and kept growing JUnit and that was fun. We always said it would just be as simple as writing System.out.println() but fully automated. I think after half an hour we could write our test for the framework within itself, and that's how we bootstrapped it. From then on it went on. We always pair programmed it as long as we had the opportunity to do this kind of what we called "Recreational programming", and that's how we have grown release 1, release 2... Then I guess people found it, got interested in it and it was really interesting... I think the key was it makes writing tests as simple as writing this debug statement.

That was the point and it was very simple, doesn't have a cost, doesn't have a learning cost, and it was a major break, right? So where we didn't have face time, we started to remote pair program using screen-sharing, stuff like that, so that's the point when... usually Kent was sharing the screen, which means he sees all his commits shown in the repository, right? But then we started on JUnit 4 with again the idea of leveraging the new Java facilities to make it even simpler, reduce more framework dependencies. Of course, at the same time, looking at what happened with JUnit on .Net, with NUnit, looking at what TestNG has done, which is all cool stuff. But we always want to preserve this simplicity we've had from the beginning. And I think since JUnit 4... I've retired a little bit and now Kent and David Saff are driving the whole thing.

One of the other things that you have been involved with was a book about design patterns and identifying several design patterns. How do you identify a design pattern and how can you tell a pattern from an anti-pattern?

Wow. So your questions really go back in time now, so it will be getting more complicated for me to answer. Design patterns, yes. I still like them and I still like to find them and talk about them. How to identify them - it's really reading code and looking what works. If you get a warm fuzzy feeling when you look at a design, "that's kind of neat", that's non obvious, right? A linked list is not a design pattern, right? It should be something non-obvious and I guess then once you identify that and you have this nice feeling, "Wow, that's neat", then I guess that's the first moment of an emerging pattern.

But before still I guess... our rule also when we did our book was a single instance doesn't make it a real pattern. So this is kind of what then you call the rule of three at that point. So once is an occurrence, twice is I don't know what and three makes the pattern. So you really have to find out... the same kind of structure, could you identify it somewhere else, because this gives us confidence in the mileage, that something is a pattern which has potential. But in retrospect when I look at our patterns in the book, not all are at the same quality level, so if I look at my hit list they are not all number ones.

And there was some voting off the island exercise, I guess some years ago at OOPSLA they picked some patterns which they would vote off, kind of the initial set and I agree with most of that, because some patterns which we kind of just thought "Oh, that's kind of neat", and we like it, that's still not enough. Because you found it cool, like Visitor: "Wow, that's so cool, you can have this orthogonal behavior", but it is just a limited use, works very well with ASTs, abstract syntax trees, things that have a fixed hierarchy, and non-extensible types. So I think the multiple uses give you the confidence that a pattern is a pattern. Other than that, you have to try to describe it, that's the next thing.

That's the easy part, identifying these patterns is easy, trying to describe it so that someone else understands it and can reproduce it, that's where the fun starts, and that's where it's very hard to do it alone because you need to do it iterative and also it really helps if you have a review process by others and pattern community have educated that how you could do that with all their nice ceremony you have with writer's workshops, review cycles. So I think it really takes more that one iteration to write a pattern and if you look back at our book, I think each one was written at least three times: it was written, re-written, but then again when you had something it was reviewed by all four authors more than once till you finally were happy with it.

And I still like patterns, right? So as I said also when we did Eclipse it was really fun to actually start to explain some of the Eclipse architecture with patterns, that's what I tried to do in the Contributing to Eclipse book, there is a chapter in there where I really tried to explain -- oh, Kent Beck is co-author of that book -- I tried to explain the architecture of Eclipse with patterns. For me it was a great test because Eclipse wasn't done kind of, "we use patterns", whatever, right? So it was experienced developers, they understand the craft of doing object design very well, so it was interesting to me in the end to... if you look at the architecture and designs in there, how much coverage do you get by explaining key things with patterns?

It was pretty pleasing to me to see that there was some good coverage and some key points that could be covered with patterns. Others not - so the key point of declarative extensions, different declarations, the whole XML thing, is something we didn't cover. I also must say that people should not forget Design Patterns happened all before the Internet, before Java, before XML, whatever. So it is amazing that it is still getting some traction, people still read it. So it is kind of interesting that some part of object design things survived all this technology base. But at the same time, to me it is indicative that there's also an opportunity for more patterns to now leverage these new technologies.

One of the comments that has been made recently in the community is that some believe that the application of a design pattern could be considered a code smell or an architecture smell, when you look at something like the 'Don't Repeat Yourself' principle. When you look at the 'Don't Repeat Yourself' principle if you are applying the same pattern several times in the code, in a sense you are repeating yourself and creating duplicate code. What are your thoughts on that?

I think one of the real strengths of patterns is that they are very flexible when it comes to their use. A pattern describes to you how to do something and gives you some things to consider. But it can be highly tweaked, right? Even when I apply a pattern more than once I will vary it and I will use it differently. If I use exactly the same, then I agree -- then why don't you try to put it and extract the commonality if you have done it three or four times? But typically what I like about patterns is the flexibility, you tweak it, right? You tweak it when you use it to your particular problem.

Never used the class names we give in the pattern for it - that's wrong. Use the domain-specific names, make it very specific to what you use. And this also excludes some of them from just putting them all in a library. The variation I think is the important thing.

You are not involved with patterns as such these days. Are you concerned that people aren't carefully handling and that the poseur books have come out and have taken over?

So, first of all no, IP - I think every software developer today has to be able to verify IP, that's just unhealthy if you say you are a software developer and you have no basic IP education. About other people taking over and referencing the patterns, no - I am not concerned at all, that's community idea, you want to really have a community.

That was some smart minds... again it's the commonality between Eclipse and patterns, the commonalities to me is communities. There is a community for Eclipse and there is a community for patterns, and you should not block growing community around that. So that is perfectly fine with the community handling, what they do... also the critique on the Gang of Four patterns is really well taken. Not that I agree with all of it, but there is of course good stuff happening in the community and it is also interesting how the community is reinventing themselves right now, there's a new generation of people in there right now.

Is there ever going to be a sequel to the Design Patterns book? The Gang of Four book?

We would love to do that. We actually started that and we have an outline, is that enough? But it is kind of interesting that we have tried to write it, and as I said I still love to write patterns and it's just our responsibilities from all the Gang of Four members and of course unfortunately John Vlissides has left us last year, so there will be not the same feeling, only three of us left, but I would love to write one. But I cannot promise more than the outline right now. And from outline to book, whoever has done a book knows that the sweaty part is from eighty percent to a hundred percent. And the outline gives you ten percent so you know how far away we are.

Is dependency injection a pattern or not?

I think it could be captured as a pattern. There are a lot of tradeoffs in there, it would fit into the whole creational realm. In our outline that is one of the things that we want to look into, how you capture it as a pattern, right? There are lots of variation how you do it - constructor-based, parameter-based, whatever, there are tradeoffs. I think that is what makes a pattern interesting, can you describe a solution with tradeoffs and to make it concrete so that I can apply it. It's a non-obvious one. I would start and try to do it as a pattern, but before having written it, it's not clear.

But that is exactly an example of this new technology, right? More declarative dependencies that I think we have done some of it in our Design Patterns, right? In Design Patterns we talked a lot about abstract coupling, that you can couple things by an abstract class, that the reference is only to an abstract class interface, and to me that's just the next level, right? You are not coupled actually to type anymore, it's really just externalized. And that's I guess an interesting next step that we haven't covered in the book, but that is something we would look into.