---

The JCP Program Management Office (PMO) held a dinner Monday night at the 2005 JavaOne developer conference to recognize sixteen JSR spec leads in the Star Spec Leads program [1]. The aim of this new program is to reward spec leads who have demonstrated outstanding leadership in the past year as indicated by the quality of the specifications they produced, and their promotion of best practices and willingness to mentor others. The spec leads were selected based on the results of a poll of JCP expert group members, Executive Committee members, and PMO staff. Here's a list of the sixteen star spec leads chosen for 2005:

• Alejandro Abdelnur, Sun Microsystems
• Volker Bauche, Siemens AG
• John Buford, Panasonic Information and Network Technologies Laboratory
• Ekaterina Chtcherbina, Siemens AG
• Linda DeMichiel , Sun Microsystems
• Andreas Ebbert, Nokia Corporation
• Jan Eichholz, Siemens AG
• Stefan Hepper, IBM
• Mark Hornick, of Oracle
• Jere Kapyaho, Nokia Corporation
• Kimmo Loytana, Nokia Corporation
• Eamonn McManus, Sun Microsystems
• David Nuescheler, Day Software
• Eric Overtoom, Motorola
• Vincent Perrot, Sun Microsystems
• Jim Van Peursem of Motorola

Monday night we spoke with several star spec leads. We asked each the following two questions:

1. What was the key to the success of your JSR?
2. What advice would you give to first-time spec leads of new JSRs?

We asked each spec lead the same questions, because we wanted to see what was common among their answers. We wanted to find out what is important in leading a distributed, technical design and development effort. In this article, we highlight some of the answers. If you have any opinions on the comments of the spec leads, please post them in the Articles Forum Topic, Seven Secrets of the JSR Spec Leads.

1. Understand what you want

One bit of advice that emerged from our conversations was the importance of defining well the target being aimed at:

Eric Overtoom: We did a good chunk of upfront work to make sure that both companies [initiating the spec] understood what we wanted to do, and that we had a proposal in place before we actually started things and kicked off with the expert group.

Kimmo Loytana: The greatest challenge is to be able to agree on what the requirements are, the JSR's goal. Once that's agreed on, doing the technical work of designing the API and writing the spec, that comes sort of by itself. But agreeing on the requirements is the hardest part . . . You don't want to cover all possible topics in the first release, but keep it still reasonably small. [That way], you can start with something and have a good spec for the first release, and then add more features later. Avoid trying to do a very big and complex [spec] right from the beginning.

2. Get the right people

Another common theme was the importance of getting the right people involved in the expert group:

Kimmo Loytana: You should ensure that all relevant companies and people get in the expert group . . . Getting the right people first makes it easier to get on with the real work.

Jere Kapyaho: Getting all the relevant players in the beginning makes things much easier, especially in later stages of a JSR. When someone comes in late, they might have comments that were already resolved in the process earlier.

Eric Overtoom: We did a fair amount of work to make sure we had the right expert group, even before submitting the JSR proposal. We communicated with other [companies] to find out if they had any interest [in the JSR], got their comments, and what they thought should be included in the scope . . . We made sure we got all the appropriate parties involved in [the JSR]: device manufacturers, mobile operators, VM vendors, and application developers—all the people interested in using this thing . . . Having both the users of the JSR and the developers involved was one of the biggest benefit for us. Often, things that look really nice from the manufacturer side, say, when writing the class libraries and the implementation, aren't necessarily good when writing an application and using the standard.

3. Delegate

Another point made by several of the spec leads was the importance of distributing the work load:

Andreas Ebbert: An expert group means you have actual experts in your domain sitting there. You [should] transform that group of experts into a team with a common goal, one that really works well together towards that goal . . . I view my role more as someone who organizes the expert group, but does not do all the work there. If you distribute the work [in the expert group], the JSR gets done quicker than if you relied on just one or two people.

Ekaterina Chtcherbina: It's important to distribute work. You have to know what each expert group member's experience is, and then distribute the work according to their experience. In our case, that was relatively easy. We wanted to cover different [mobile telecommunications] protocols, and companies on the expert group each had strengths in those areas. Since we also cared a great deal about interoperability, we were also able to get their input about interoperability.

Kimmo Loytana: It shouldn't be only the spec lead doing the work by himself, but the whole group should be involved . . . As a spec lead, organize appropriate meetings for the group, involve them in discussions minutes, and then discuss some design principles. Then try to divide the work so at least some active members share in that work.

4. Foster communication

Probably the main point made by all the spec leads we spoke with was the importance of fostering communication within the group to draw out the collective wisdom of the experts:

Kimmo Loytana: The most important thing is to get the whole expert group involved, and have real active discussion.

Ekaterina Chtcherbina: Where I see the value of the JSR lead is to support effective means for communication and exchange of opinions. Every spec lead does that in a different way. In our case, we try to [facilitate] regular communication sessions, conference calls, face-to-face meetings, reply to emails, and motivate people to provide their opinions and feedback.

Kimmo Loytana: Lead the work so that all the issues are actively discussed and decisions are made together.

Jere Kapyaho: It's mostly about communication. The expert [group] participants can't typically devote themselves full time to the [JSR] work. They are doing other tasks asynchronously . . . We're geographically separated, mostly on different sides of the Atlantic, and you get time differences, so email is the most reliable communication method.

Andreas Ebbert: I see my role as a moderator and enabler between the experts. Instead of telling them, "OK, we're doing this, what's your comment on that," it's better to entice them to communicate actively. The expert group members have to know that their opinions are valued in the group . . . Email is the only communication means left [in my case], because my expert group spreads from Australia to India, Europe to California. It's hard to find a good time for teleconferences. We still have them every week, but you don't get the whole expert group on the teleconference because of the time zone problems.

Vincent Perrot: Face-to-face meetings and communication with the architects coming from different companies is crucial. We try to meet face-to-face as much as we can. That's where we can see real progress on the JSR. Phone calls are good enough if you know each other. But face-to-face meetings help synchronize our work, and help ensure we're working on the right goals. The JCP provided us with a Web site to share information, but now Java.net is what we use most. We share code in their CVS, and you can create your own hierarchy of documents.

5. Keep the ball visibly rolling

Several spec leads mentioned the importance of continuously driving the progress forward, as well as keeping everyone informed of that progress:

Kimmo Loytana: The spec lead has to lead the work and keep the schedule so the JSR is able to finish its work in a reasonable time.

David Nuescheler: If you have to take a decision as a spec lead, take that decision and then stick with it.

Kimmo Loytana: You have to go through a lot of meetings . . . we've been holding weekly conference calls, face to face meetings at a couple of places, so that all those in the expert group know what's going on and have a chance to comment on it.

Jere Kapyaho: You really need to keep the expert group up to date of what you're doing, when you're going to publish drafts of the specification, of what you're doing about the comments they sent in. I don't think anyone would want to be sending comments into a black hole and not being able to find out what's happened to [those comments]. You really need to acknowledge the comments from the expert group, and then tell them what you're doing about them, and when the issue is going to be resolved. Or just telling people when you're having the next meeting. You would think these are small things, but these things count.

David Nuescheler: Make sure everyone knows what's going on. People in the expert group don't know the process that well. They need to see the next steps.

Vincent Perrot: Make things as transparent as possible. You are not trying to hide things, anyway, so just share information with others. That encourages everbody to contribute. My very first experience in leading a JSR speaks to that. At that time, there were just two companies, each a leader in that domain. At the beginning, we had a face-to-face meeting, a dinner, as a way to start the JSR, but we didn't share any information with each other. After the dinner, I went back to the office, and during the night I coded the first [draft] of the JSR, which was very basic. Next day, I showed people the possible interfaces we were going to work on. And then, magically, the [expert group members] at each company started to chip in with comments: "Why do you throw an exception here?" And then others would reply, "Well, that's what the standard says, but this is how we actually implement it." And then others would comment, "Yeah, that's how we implement that, too." Then, all of a sudden, the expert group members from different the companies that were previously not talking to each other just started exchanging information. And then the JSR became very successful.

6. Accomodate agendas without sacrificing technical excellence

We also heard that while it is important to strive to accomodate everyone's business agendas, you should strive to not allow political compromises to be at the expense of the technical merit of the result:

Jere Kapyaho: In the J2ME space, there is definitely competition on the surface. When you have an expert group with people from Nokia, Siemens, Motorola, there will be different and sometimes even conflicting interests. Luckily, we're mostly working on a technological level. We don't get much wrangling over market interests. Of course, we do have to develop APIs that fit with our [product] portfolio. But, in the end, it's the technological decisions that impact the API&#8212what's better for the developer. We don't let the market interests impact the API. Often, you have to make architectural decisions at the beginning of the JSR, and some of those choices might not be very good for the developer. You know the joke about the camel being a horse designed by committee. If you're not careful about that, you may end up with an API that doesn't fit into anyone's idea.

David Nuescheler: Each [expert group member] has a business agenda, and it's important to cover as many business agendas as possible without losing the technical credibility. So it's as much a diplomatic as a technical mission to get the first version of a JSR done. You have to find the balance, the consensus. . . A JSR is always a technical challenge, but is also, at the same time, a political discussion to make sure all parties involved in the JSR are satisfied, that all requirements are covered from the involved parties. In our JSR, 42 experts were involved, representing over 20 organizations . . . It boils down to trying to be non-confrontational, trying to build consensus. The JCP is very much about compromises. Make sure everybody is on board about certain topics, that everyone can live with the compromises . . . Before taking a vote on things, try to build consensus.

7. Learn from others

Lastly, we heard that it is beneficial to seek guidance from those who have gone before:

Jere Kapyaho: I'm actually the second generation of the Nokia spec leads. I've had the benefit of standing on the shoulder of giants, so to speak. Other Nokia spec leads before me would have deserved this award a lot more than I. I was lucky to have a lot of excellent people to ask stupid questions from, in addition to having my own instincts of how to lead this group of a wild bunch of experts that possibly want to pull in different directions based on by their agendas, companies, and maybe individual interests, too.

Conclusion

What we personally learned from these JSR spec leads is that you have to have a strong, but still realistic and not overly ambitious vision when starting a new JSR. You have to know all the important players in the domain, and be able to convince them to work with you on the JSR. Once your expert group is in place, don't attempt to do all the work yourself: Instead, delegate as much work as possible to your expert group members, while keeping them informed of what's going at any time. You also need to be very responsive; for instance, reply to emails right away. A healthy doze of diplomatic ability is also crucial for success, as you will need to reach consensus without compromising on the

To sum up the overarching themes of our discussions with the spec leads: the key to leading a successful JSR is to get the right people on the expert group, and facilitate communication between them. It is important up-front to agree on the requirements, and throughout the process to be responsive and keep everyone informed of the status and next steps. Face-to-face meetings are the most productive, but the asynchronous nature of email is usually the most

How do you lead a successful design, development, and specification project with a distributed team of experts? In short, bring the right people together in your expert group and facilitate communication between them.

-->

Resources

[1] Information about the Star Spec Lead Program and links to detailed bios of the 2005 star spec leads is available here:
http://jcp.org/en/press/news/star

Talk back!

Have an opinion? Be the first to post a comment about this article.

About the authors

Frank Sommers is a Senior Editor with Artima Developer. He also serves as chief editor of ClusterComputing.org, the IEEE Technical Committee on Scalable Computing's newsletter, and is an elected member of the Jini Community's Technical Oversight Committee. Frank is also founder and president of Autospaces, a company dedicated to delivering rich-client Java enterprise solutions to small and medium-size businesses. Prior to joining Artima, Frank wrote the Jiniology and Web services columns for JavaWorld.

Bill Venners is president of Artima Software, Inc. and editor-in-chief of Artima Developer. He is author of the book, Inside the Java Virtual Machine, a programmer-oriented survey of the Java platform's architecture and internals. His popular columns in JavaWorld magazine covered Java internals, object-oriented design, and Jini. Bill has been active in the Jini Community since its inception. He led the Jini Community's ServiceUI project, whose ServiceUI API became the de facto standard way to associate user interfaces to Jini services. Bill also serves as an elected member of the Jini Community's initial Technical Oversight Committee (TOC), and in this role helped to define the governance process for the community.