About JCP
Get Involved
Community Resources
Community News
FAQ
Contact Us
|
|
Press and Success
Success Stories
Wireless
Expert Group Divides and Conquers
JSR
37
"Divide and conquer"
is a strategy that helped one expert group within the Java Community
ProcessSM (JCP) program work through
their Java™ Specification Request (JSR).
Division of Concept
Just before
the 1999 JavaOne SM conference,
Mark VandenBrink, Chief Architect of Motorola, composed a JSR. At
the time, there was no such thing as Java™ 2 Micro Edition
(J2ME™) and no notion of configurations and profiles.
In conversations with several people at Sun, those ideas were born,
and it became apparent that the original JSR needed to divide in
two. JSR 30: J2ME Connected, Limited Device Configuration (CLDC)
and JSR 37: Mobile Information Device Profile (MIDP) for the J2ME
Platform formed the basis of the terminology of configuration and
profile, now common in Java technology parlance.
Division of Expert
Group
As spec lead
for JSR 37, Mark played the divide and conquer strategy again. His
22-member expert group -- experienced in wireless communications
and well-versed in Java technology -- split in two teams to work
on MIDP JSR 37. Nokia representatives led a team to take on the
challenge of user interface issues. Sun Microsystems spearheaded
the second team's efforts on networking (HTTP), persistent storage
(RMS), and timers/miscellaneous. Mark and his Motorola colleague
Jim Van Peursem maintained overall leadership and contributed to
the RMS part of the specification and the low-level graphics frameworks.
Division of Time
Gathering representatives from all over the world -- Europe,
Canada, Japan, and so forth -- was quite a logistical feat. Taking
advantage of the fact that many of his experts also served on the
counterpart JSR 30: CLDC, Mark scheduled his two-day meetings to
follow the one-day CLDC meetings. On average, over 95 per cent of
the experts were able to attend each of the four meetings. They
received a detailed agenda in advance, and meetings adhered to it
pretty closely. Mark recalls the challenge of "level-setting"
expectations at the first meeting, when he had to help 22 companies
comprehend and buy into J2ME technology, a radical departure from
Sun's previous approach of "subset based on size."
Mark's
Words of Wisdom
for Spec Leads:
 |
First,
say no. |
|
Say
no again. ;-) |
|
Set
the overall goals and timeline in the first meeting.
If that is all you accomplish, you have a good
leg up. |
|
Establish
a policy for adoption of suggestions. Jim Van Peursem of Motorola made a simple rule, "code
beats paper." Those who suggest altering
the spec must be ready to back it up with working
code. |
|
Expect
to travel. A lot. Face-to-face meetings work
better than email for building consensus among
wildly divergent viewpoints.
|
|
Simplify
your spec. Use YANGI -- "You ain't gonna
need it" -- as a mantra. |
|
Be
organized to the extreme. If your expert group
is clicking on all cylinders, they will generate
a lot of email and documents. |
|
Keep
track of every suggestion. Respond to every email.
It gets tougher during public review when hundreds
pour in, and most start, "Dear Stupid, How
could you have left out <insert your favorite
feature>...." |
|
Get
technical writers involved. For the most part,
engineers don't write particularly well. |
|
Get
a test engineer involved early. TCKs are tough
enough to write. |
|
The
process usually involves going through the spec,
identifying <i>assertions</i> about
how the code should behave. Without an experienced
test engineer to help shape those assertions,
you will pay later. |
|
Keep
the mood light. Remember we are all human, we
make mistakes, and we will disagree on some issues.
Build relationships and compromise to achieve
the end goal. |
|
When
the spec comes out, be prepared to be castigated
as well as praised. |
|
|
Mark says, "Since
this was a totally new field, these pioneers were essentially blazing
new trails. This extremely impressive group of folk agreed early
on to limit the scope and get JSR 37 out in record time." With
JSR 37 approved on September 27, 1999, the first meeting occurred
two months later. The next three meetings took place about every
six weeks after that. Participant review closed in April, public
review closed in June, the specification was first released in July,
and the JSR went final September, 2000, just a year after it all
started.
Division for Consensus
Drafts of the
specification were released early and often to keep everyone updated.
About ten of the 32 spec releases were sent out to the group at
large. The expert group's primary communications venue was email.
After the first meeting, the group worked through issues that had
been brought up using an extremely active majordomo mailing list
-- about 3000 emails circulated during its lifetime.
JSR 37 expert Roger Riggs,
a senior staff engineer at Sun Microsystems, notes, "Email
is very good to get issues onto the
table. Face-to-face meetings are more valuable to solve difficult,
multi-dimensional questions. By supporting those two activities
and using standard project management techniques -- issuing schedule
reminders and stressing the need for particular outcomes and constraints,
Mark got people to align around particular solutions." When
participants expressed radically different opinions too difficult
to address in an open email forum, Mark traveled the globe to meet
face-to-face with groups and individuals, where he pushed for clarity
on positions and consensus.
PMO Unifies Process
As the first J2ME profile to start and finish, this group learned
the Java Community Process program the hard way. In practical terms,
that meant consulting the Process Management Office (PMO) to clarify
issues in the JCP 1.0 process that were vague and to discover, for
example, which experts had signed a Java Specification Participation
Agreement (JSPA).
"The PMO was extremely
helpful in answering questions and listening to our experiences
for feedback into the next JCP process," says Mark. He feels
that most of his suggestions were taken seriously and incorporated
in the creation of JCP 2.0. The new JCP.org web site implemented
several of his early suggestions, including a home page for each
expert group, mailing list, and other ideas. "The JCP is getting
better. There are some wrinkles to work out, but by and large having
a place to standardize Java APIs in a non-political setting is a
good thing," says Mark.
Roger, a veteran participant
in industry standards groups, appreciates the Java Community Process
for its ability to garner broad participation from many interested
companies who are eager to make progress so they can get the technology
to market. He says, "The JCP tries to focus on the technology
and not the business interests or the market-driven concerns. The
process works well when companies bring expertise and technology
and when they have the resources to contribute fully to the process."
Wireless Industry
and Consumers Benefit
JSR 37 arose
not from personal whim, but from industry need. According to Mark,
"Wireless is moving from being voice-centric to having a large
data component. In order to take advantage of this, we in the wireless
industry needed a programming environment on the small devices."
Wireless, two-way communication devices -- such as cellular phones
and two way pagers -- vary radically in form and function, with
myriad screen sizes and input devices. Because there is so little
commonality in devices today, the expert group tightly focused the
scope of the problem by starting with a small subset of what members
believed would be needed in the future.
While the process of
hammering out JSR 37 flowed fairly smoothly, Mark found the writing
of the Reference Implementation (RI) and Technology Compatibility
Kit (TCK) difficult. He says, "Writing an RI that matches a
spec and having a TCK that ensures interoperation is extremely tough."
Nevertheless the expert
group rose to the task. "Because the specification was debated
in an open and very technical manner, I think we got very good consensus
and buy-in from the expert group companies." With the specification
now final, Motorola, Nokia, Siemens, Symbian, Research In Motion,
and many others have launched or will soon be launching products
based on JSR 37.
Mark felt relief when
the JSR closed, as well as a certain pride in having seen it through
from ground zero to product launch. Now he waits to see how consumers
will respond to having rich and appealing content delivered to wherever
they are.
JSR
37 Home Page
|
