Jazz Technical Lead Erich Gamma Answers Your Questions

Jazz Technical Lead Erich Gamma Answers Your Questions 54

Posted by ScuttleMonkey on Wednesday July 08, 2009 @03:30PM from the direct-line-to-the-experts dept.

Last week you asked Jazz technical lead Erich Gamma questions about Jazz or anything else in his realm of expertise. Here are his answers, along with many external links and places to continue the conversation if you are interested.

Why Jazz? -- by autophile (640621)

Could you explain, minus the marketing speak that seems to pervade the IBM site, what is Jazz, what makes it a community-oriented developer's site, why is it different from, say, sourceforge.net, and if Jazz is so community-oriented and yet apparently tied in to Rational, where are the community versions (not trials, not demos, not limited to the point of uselessness functionality) of Rational products?

Jazz is not a product but it is the name of a project that has the goal of building a new set of team products and to better integrate existing products.

The Jazz project was kicked-off in 2005. At that time we observed that the tooling situation for an individual developer using an IDE like Eclipse was pretty good. However, when it came to working as a team, our own experience and feedback from our customers indicated there are still many pain points. Our own experience comes from working for many years on Eclipse. We developed in a globally distributed team, spread across many time zones, and using many agile practices. The goal of the Jazz project was to take a fresh look at how teams work together and to build a new generation of products from the ground up that makes development more collaborative, but also more fun. We put the team at the center of all our designs. Initially we focused on development related pain points like support for iterative planning, painless build submissions, collaborating and fixing broken builds, simplifying parallel development, easy progress tracking, and finally improving transparency. Collaboration becomes more effective with increased transparency. One of the goals here is to make it easy for everybody to know what is going on in the project without having to ask. Since then we expanded the scope to cover the role of testers and business analysts. The set of new products that were built from the ground up include:

Rational Team Concert (RTC): Provides a new customizable work item/defect tracking system, a continuous build system, a new source control system, and customizable agile planning that supports project management practices like the ones from Scrum, and dashboards and reports. Version 2.0 has actually shipped just a week ago.
Rational Quality Manager (RQM): Provides test management, test planning, and includes a test lab management component.
Rational Requirements Composer (RRC): Provides requirements definition for business analysts, client stakeholders and software developers using a variety of capture techniques.

These products share a common infrastructure using the building blocks we refer to as the Jazz Foundation. The Foundation provides a common set of services that can be leveraged by a Jazz tool. To enable integration with existing tools, the Jazz Foundation supports the Open Services for Lifecycle Collaboration initiative; an independent project to define a set of REST based protocols for sharing information across disparate tools. Actually, we are not only contributing to the specification, we have actually used the OSLC specifications for integrating the above tools.

Finally, we have grown a community around the Jazz project on www.jazz.net. Transparency and feedback are very important to us, not only for the tools we provide, but also for how we develop the products ourselves. To get that direct feedback, we do our development on jazz.net out in the open. On jazz.net you can interact with the development team, learn about our development plans, see our RTC powered dashboards, submit defects and enhancements, or download intermediate milestone builds.

If you want to read about how all these capabilities come together, there is a new eBook available for download. The eBook describes, using scenarios, how business analysts, development teams, and testers collaborate using the above mentioned products.

If you are interested in how we develop our products using Rational Team Concert in a globally distributed team, I did a web cast that sheds light on our development practices.

Rather than reading feature comparisons, I suggest that you jump in and give Rational Team Concert 2.0 a try. We made it very easy to kick the Team Concert tires. In less than 30 minutes you will have a running server, a client, and a sample project for a small team working on a fictitious JUnit release. There is also a community edition called Express-C (free for up to 3 users). Based on community feedback, we have made more features available in the Express-C edition. You can find the descriptions of the editions on the Jazz site. For those of you that do prefer to compare features, there is also a feature overview of RTC . If you have questions, feel free to post them to the user forum on jazz.net. Our development team is always there to answer questions.

Rational? -- by an anonymous reader

I work in a small shop that makes some use of Websphere Application Server and the Rational development tools. I basically find the entire structure of the IBM software offerings relating to the above technologies incomprehensible. Products are constantly being renamed, discontinued, bundled, unbundled and rebranded. Names are long, generic, and practically interchangeable, and so are the feature lists. How do you plan to run a community support site based around this hodge-podge? I would assume the volatile nature of IBM's software marketing makes your task something approaching impossible. How do you expect to build a strong developer community based around products that are in a constant flux? I don't see any way around ending up with a large number of granular, isolated communities that spring up around specific products and thrive for a year or two. In short, how do you plan to unify a developer community without IBM first unifying the software development platform that this community is to be built around?

Obviously the Rational portfolio has grown through acquisitions (Build Forge, Watchfire and Telelogic being the most recent), and the process of bringing these acquired products into a logical product family while minimizing disruption for existing users is an ongoing effort. One goal of the Jazz project is to improve the integration of existing products by providing the Jazz integration architecture and by contributing to the OSLC initiative as mentioned above.

The Jazz community site is the live development infrastructure for the Jazz project and the new Jazz products. We launched www.jazz.net in 2006 together with the availability of the first Rational Team Concert beta version. As you can see from the URL it is "ibm" neutral and focuses on Jazz products. Since then the community has rapidly grown and there are now over 17000 participants in Jazz forums. Customers really appreciate the direct communication channel with the development team. Given the positive feedback we have recently on-boarded two additional Jazz products on jazz.net: Rational Requirements Composer and Rational Quality Manager. This was combined with a reorganization of the site itself to optimize for the new projects, improve user experience, and create a high quality technical library of materials created by the development teams themselves to help educate and get teams set up and running and become productive very quickly. Additional Jazz products will on-board on jazz.net as they emerge. Some of the Jazz products will also be in flux, the point is that we make them available early, are transparent about their development and invite users to provide feedback.

RTC vs CQ and CC -- by SunSunich (1588709)

First of all let me congratulate you on the successful launch of version 2.0 of RTC and 1.0 JF. It is really great work, thank you and all the Jazz Team. The functionality of Rational Team Concert greatly overlaps with the ClearQuest and ClearCase. Why is it necessary to create a new product? Why not just release it as new versions of old? For customers, it could be easier to adapt. What is the future of CQ|CC, how you see it? Thank you.

With the Jazz project we are trying to do something new and do it in the open - but clearly we understand that we can't just leave the existing customers behind. As mentioned in the question about the Jazz project above, we have experienced several pain points with the existing tools. A common point of friction was the lack of integration which resulted in a lack of transparency. One lesson from Eclipse was that to achieve integration you need some common foundation or integration platform. Retrofitting a new integration platform wasn't a viable approach and in addition there were additional pressures to better support agile practices. While the Jazz project did start from the ground-up, we reused many ideas from CC and CQ. For example, the stream model from CC or the customization support from CQ. Once we went down this path it was obvious that we needed an integration solution for CC and CQ.

In RTC 1.0 we provided "synchronizer" connectors which can synchronize data between the Jazz and the CC or CQ repositories. With this functionality, an agile team can start to use RTC while periodically synchronizing their code with the "mothership" CC repository. For RTC 2.0 we have expanded the integration options with the support "bridge" connectors. A bridge doesn't synchronize the data but rather links artifacts across repositories. The CC Bridge allows linking a ClearCase UCM activity with an RTC work item. This allows CC users to continue using CC, but also benefit from the additional capabilities RTC offers such as agile planning support, work items, reports, dashboards, notifications etc. The CQ Bridge provides linking CQ Records and RTC work items. Finally, both RTC and CQ implement the Open Services for Life Cycle Collaboration specification for change management systems. This enables a third tool like the Rational Quality Manager to work with either RTC or CQ when it comes to filing defects for failed tests, for example.

To conclude, there is still a significant investment in enhancing ClearCase and ClearQuest and this will continue. RTC 2.0 provides good options for users who want to use RTC, CQ and CC together. All these options have been enriched further in 2.0 to enable gradual adoption.

Could Jazz Benefit from a Distributed Model? -- by A.K.A_Magnet (860822)

Do you think Jazz could gain from a distributed model, like git does for source control management, where the repositories can be forked and kept synchronized upstream/downstream (a bit like a "progressive fork" where fixes can be shared but the project can be forked for various reasons)? I heard there is a git connector in incubation but it seems to me more than just code artifacts should be distributed. After enjoying the many benefits of distributed SCMs, it's hard to go back, and I think at least issue management could gain from the same model.

Using the terminology from above the Git integration will be a bridge connector. It will be available as an incubator on jazz.net soon and it leverages the OSLC change management specification supported by RTC to create the linkage to RTC work items. Flowing changes across repositories is appealing and this feature is in our backlog. Some explorations to support a distributed Jazz SCM were already undertaken. Details on the current status and open issues are available on the developer wiki on jazz.net.

Cleaning Up Collaboration -- by eldavojohn (898314)

Jazz seems to rely heavily on developer community and their collaboration--and the influence for Jazz is said to be the World Wide Web. "The Jazz portfolio consists of a common platform and a set of tools that enable all of the members of the extended development team to collaborate more easily." The biggest problem I have with collaboration tools is the metadata. No one does it right. Someone writes a blog or uploads a document but doesn't tag it. Enterprise search is broken. Management hands us wikis yet no one has the time or patience to maintain them. The protective blanket of "it's agile, baby" shields us from any beat downs. And with every new tool I realize that it's not the tool that improves collaboration, it's the team. Look at Slashdot's tagging system. Does it help me that one hundred stories are tagged with "no"? Collaboration seems to spontaneously work but is often out of your control when it does and doesn't. How does Jazz fix these problems? How does Jazz improve collaboration when it seems to me that tools are such a small part of collaboration? Will a small development team be able to use such a large set of tools?

I agree that no tool can fix collaboration problems and the team plays the main part in the game. In the Jazz project, we are focusing on collaboration in the context of software artifacts like builds, change sets, test plans, defects, or baselines. Software artifacts are semantic rich, structured, and there are typically rules, permissions or approvals involved when it comes to changing artifacts. Jazz products can improve the collaboration around software artifacts by making these rules explicit. Our goal was that the tool not only acts as the police but also as a guide that helps team members conform to the rules. Let's use Rational Team Concert as an example. When a change set requires a review before it is shared with the team, the tool will not just flag you when the review is missing, it also offers to initiate the review process for you. This involves suspending the changes from the current work space, attaching them to a work item, and notifying the reviewer that there is a pending review.

Behind all this is a process component in the Jazz Foundation that allows you to configure these rules in a flexible way. The flexibility is required since otherwise tools can get easily in the way. A team operates differently during an early exploration of a product and one week before it ships. The rules can be specific to a particular role, or a particular team, and the development phase of the project. Here is an analog example to tagging a blog: checking in a change set and wanting to track the reason for the change. To guide users, you can define a precondition for the check-in operation that will ensure that the change set is linked to a work item tracking the reason for the change. When a user attempts to check-in a change set without an associated work item, the user is shown a list of work items that they own to choose from. If none of them apply, the user can easily create a new work item on the fly to complete the check-in. As a side effect the change set and the work item are now linked together. As you work with Rational Team Concert it establishes many such links between artifacts for you in the context of your work. For example, the work items that are fixed and included in a build are linked to the build result artifact. These links increase the transparency and allow everybody in the team to understand why something was changed, which will helps collaboration.

In addition to making team roles and rules more explicit, the tools improve collaboration by helping team members stay on top of changes that affect the whole team. The team's current sprint or iteration plan and the current progress are easily accessible for everybody to see. Team members are notified about events in their team and they can track event feeds using RSS readers and aggregators. Similarly, broken builds are linked to a work item where the discussion about the broken build takes place and this work item is then easily visible and accessible from the team's dashboard. These are just a few examples that illustrate how a tool can facilitate the collaboration in the context of software artifacts.

Now regarding the question on small development teams, RTC is designed to scale up from single teams working in a single release to multiple (even distributed) teams working on multiple releases and you can easily use RTC for small teams. In fact, the Express-C edition is free for teams up to three. Even a small team needs to do the backlog and sprint planning, needs continuous builds, needs to track progress, manages defects and wants to make the current state of the project visible on dashboards.

The Directions of the Eclipse Foundation -- by eldavojohn (898314)

Eclipse has been going on since the early 2000s and six days ago enjoyed the release of Galileo (v3.5). If you've had time to look at recent release, what are your opinions on what Eclipse has become? Has it made any wrong turns? How do you respond to criticisms of "bloat" or "too resource intensive"? Do you see it becoming more than what it is or transforming?

The Galileo release is quite an achievement. Over 30 projects with over 380 committers from over 40 organizations have contributed to this joint release. Obviously you do not want to consume Galileo all at once but rather pick one of the available packages that suit your needs. Now that my team's focus is on Jazz and Rational Team Concert, we have become consumers of many Eclipse projects. Having a release train with aligned project releases is a big help for us and is the right direction.

As consumers we also appreciate the API stability that Eclipse platform provides. Regarding bloat, the API stability is not free. It means that once something has surfaced as an API, you cannot remove or change it anymore. For example, if you look under the covers in the Eclipse source code, you find three different preference store mechanisms. This is the price you pay for API stability. Actually, Eclipse now includes some nice tools to track API changes and more.

The "too resource intensive" criticism depends on which packages/plug-ins you are using. Eclipse is an extensible system and is therefore vulnerable to contributions that can be too resource hungry. To keep a software system interesting to users, you need a constant flow of new features. The challenge is to preserve the performance and resource characteristics as new features are added. The Eclipse SDK team does measurements to track this. There is a set of performance JUnit tests that are run for each build. Once a test runs slower than the baseline from the previous release, the test turns red. The results are published for each build. Here is an example report from Eclipse 3.5. Based on our own use of Eclipse for developing RTC, I do not experience that Eclipse has become slower over time or more resource intensive.

Looking back, I don't necessarily see wrong turns, but rather some turns we probably could have taken but didn't. For example, the Eclipse platform is language agnostic and the Java Development tools built on top of the platform. There is a language toolkit layer (LTK) in between the platform that provides some generic infrastructure for implementing refactorings. However, this layer is thinner than implementers of new languages on Eclipse would like. They therefore have to resort to copy code from JDT. This is obviously not ideal. Even though we were aware of this issue, we didn't have the cycles to pursue a more generic language layer. Having said that, I must say that the Eclipse C Development tool is cool in Galileo and there is good support for many other languages. There also is the Dynamic Languages Toolkit incubator project at Eclipse.org.,

Will SWT and Swing ever merge in Eclipse? -- Fuzuli (135489)

I have to build quite complex tools using GEF and GMF, and there are many cases where I'd like to have the power of Java2D, and reuse some of the great frameworks out there built on Swing. More and more people are using AWT/SWT bridge, since SWT does not provide an underlying drawing framework as rich as Java2D. Eclipse has great things like EMF, and the platform is number one choice for tooling, but when it comes to things like Bezier curves etc, Swing is much easier to use. So are we going to see more developer friendly versions of Eclipse where Swing is more available to us?

SWT has continually improved its advanced graphics API for drawing Bezier curves, alpha blending, gradients etc. You can see it in action in the GraphicsExample (http://www.eclipse.org/swt/examples.php.) and there are several example snippets. If the current support is not sufficient, then you should file enhancement requests against the SWT component at eclipse.org.

As you mention SWT provides the support to enable the SWT/Swing integration and enables embedding an AWT hierarchy in a SWT widget hierarchy. The SWT team has currently no plans go beyond this. However, there is also the Albireo project at Eclipse.org. This is a technology project in incubation with the goal of simplifying the task of combining user interface components from the Swing and SWT toolkits.

A follow-up question -- by an anonymous reader

will SWT and the whole Eclipse workbench ever run in a Web browser? We have built a product based on SWT/Eclipse but our customers complain they cannot run it from a browser and instead have to download 200MB+ worth of plugins before they even start evaluating our product.

The eclipse e4 project has been investigating this very question. At EclipseCon 2009, the team provided an update and showed some interesting demos. You can find more details about the e4 project and a presentation covering the eclipse/desktop exploration online.

The short answer is that there is no free lunch for existing applications which generally must be re-factored to take into account that the application is now split between client and server. For your application to run in a web browser, the libraries it uses must also run in a web browser. In particular, one needs web equivalents of the workbench facilities that Eclipse RCP apps are based on. The approach currently being investigated is to provide "e4 workbench services". The e4 project is increasing support for running JavaScript on the desktop. As a consequence when the application is written against these workbench services, the same JS code can run unchanged in both the desktop and the web. In combination, this provides a path to achieving a good user experience in both the desktop and the web with some reuse.

A different approach being investigated in parallel is the eclipse Rich Ajax Project, which is also part of the Galileo release. RAP runs your SWT widgets remotely in a web browser, which have some other trade-offs as the approach used by e4.

On strong typing, and design patterns and testing -- by bADlOGIN (133391)

A number of weak typing language zealots like to point out that Design patterns is simply a way to make strongly typed languages "suck less". This can be a compelling argument in terms of simplicity and syntax in examples when you take a look at books like "Design Patterns in Ruby" compared with "Design Patterns: Elements of Reusable Object-Oriented Software". There's also an argument that strong typing is a form of tight coupling and antithetical to half of the Object Oriented axiom, "loose coupling, strong cohesion". Given the momentum in popularity that unit testing across multiple languages and development methodologies has (rightfully!) enjoyed, is it time to encourage language designers and programmers to move away from strong typing usage and substitute better testing practices?

The Design Patterns book is now over fifteen years old and it predates the Internet, Java, and XML, which is pretty amazing to me. However, it doesn't predate Smalltalk. Smalltalk is an influential and powerful dynamic object-oriented language. When working on the pattern catalog, we looked for known uses of our patterns in the Smalltalk libraries. If you study some of the pattern examples you can see how they can be implemented in Smalltalk. What is definitely true is that dynamic languages provide some interesting pattern implementation variations. I do not go as far as to say that static typing is in strong contrast to object-oriented principles. You can define loosely coupled systems in statically typed languages using interfaces and abstract classes. In addition, the more recent Dependency Injection pattern allows you to configure the dependencies of an object externally.

On the Current State of Academia? -- by eldavojohn (898314

I know a lot of people that are very vocal about what is right and wrong with education today. Especially college institutions: "No one teaches C, everyone teaches four years of Java, no one understands the theory, a CS grad doesn't even know what a model-view-controller pattern is." The list goes on. Since you have your doctorate and have probably spent a lot of time in research and academia, what's wrong with most computer science or engineering programs in general today? What would you like to see more or less of? Are there any subject directions recently taken (EJB, garbage collectors, interpreted languages) you'd like to comment on? You seem to be non-opposed to Java which, I'll admit, is rare to me for someone with a doctorate. I would like to hear your views since so often all I hear about Java is that it is slow and only good for people that want cheap software developed quick by beginner developers.

I cannot complain about the students that come out of nearby universities and that interview for positions on our team. Many of these students used Eiffel as their first language but they are all familiar with different languages using different paradigms. While they are not experts in EJBs, JFS, Dojo, Ruby on Rails or whatever, they have a solid CS background with lectures on patterns and are eager to learn. They come up to speed quickly with new technologies. This is required when joining a team like ours working on Rational Team Concert. For example getting started on the Rational Team Concert project requires a new team member to learn a mix of things such as Java, JavaScript, Dojo, CSS, C# (when working on the Visual Studio Client), Eclipse Plug-ins, REST and finally our agile development practices. One possible area of improvement is more familiarity with larger software systems and their architectures. Open Source project like Eclipse can serve as great study material. On the positive side I also observe that more students are starting to contribute to open source projects and can point to submitted patches in their CVs.

This discussion has been archived. No new comments can be posted.