The Artima Developer Community
Leading-Edge Java | Discuss | Print | Email | First Page | Previous | Next
Sponsored Link

Leading-Edge Java
Seven Secrets of the Star Spec Leads
by Frank Sommers and Bill Venners
June 29, 2005

Page 1 of 2  >>


Java's future hinges as much on leadership as on sound technology. In this article, the spec leads of several JSRs share their insights into the key ingredients of leading a successful design, development, and specification project with a distributed team of experts. Substitute spec lead with project lead, and these lessons are relevant to anyone leading a software development effort.

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:

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.

Page 1 of 2  >>

Leading-Edge Java | Discuss | Print | Email | First Page | Previous | Next

Sponsored Links

Copyright © 1996-2018 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use