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:

What was the key to the success of your JSR?

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—what'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 technology.

About the authors

Frank Sommers is a Senior Editor with Artima Developer. He also serves as
chief editor of the Web zine ClusterComputing.org, the IEEE Technical Committee
on Scalable Computing's newsletter, and is an elected member of the Jini
Community's Technical Advisory Committee. Prior to joining Artima, Frank wrote
the Jiniology and Web services columns for JavaWorld. Frank is also president
of Autospaces, a company dedicated to
providing service-oriented computing to the automotive software market.

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.