JSF 2.0 EG Kick Off Meeting: Buy a Feature

Even though we haven't yet officially filed the JSR for JSF 2.0, we're darn close, and I felt we could not afford to miss the opportunity to have a JSF 2.0 Expert Group kick off meeting at JavaOne this year. Once again we were blessed with a great turnout (19 people, including a special visit from Jonathan Schwartz, see the roster). Instead of spending time gathering requriements or kibbutzing, I decided the requirements we have already gathered were good enough for now. Our first order of business as the JSF 2.0 Expert Group was to prioritize these requirements so we can build a schedule.

To complete this exercise, we used one of Luke Hohmann's Innovation Games: Buy a Feature. From Luke's description:

Create a list of features with an estimated cost. The cost can be development effort or something else; although the cost can be the actual cost you intend to charge for the feature, this is usually not required. Customers buy features that they want in the next release. Make certain that some features are priced high enough that no one customer can buy them. This will help motivate negotiations between customers as to which features are most important. Encourage customers to pool their money to buy especially important / expensive features. Works best with 4-5 customers in a group, so that you can create more opportunities for customers to pool their money through negotiating.

"Buy a Feature" is just one of the great games in Luke's book, Innovation Games: Creating Breakthrough Products Through Collaborative Play .

Exercising spec lead authority, I looked at 1) the JSR draft, 2) the Requirements Scratchpad, and 3) Alex Smirnov's requirements document, and picked 15 requirements using a weighting algorithm. I assigned prices to each based on how much spec effort I thought it would take to specify each feature. I took the final 15 into the meeting. JCP Experts being JCP Experts, there was some disagreement over my inclusions and omissions from the list. I pushed aside this disagreement, for the most part, and only allowed two changes to the menu at the meeting. The actual menu used at the meeting follows.

Playing the Game

We broke down into groups of four, and Roger Kitain, Dennis Byrne and I played the role of feature retailers. Dennis Byrne, who works for world-famous XP Consulting firm ThoughtWorks remarked that his firm uses similar techniques to discover the preferences of clients. From his experience in playing such games, he was very pleased with the amount of high quality discussion in the groups, and so was I. These people clearly had strong opinions about web application frameworks, but at the same time were professional in sharing them. The collaboration aspect of the game was a success, which in itself is a good outcome to a JCP Expert Group kick-off meeting.

After each of the four groups had completed their shopping, I collected the results which are summarized in the following table.

Conclusion

There were some problems with the exercise. Ever the inveterate gamer, Howard Lewis-Ship pointed out (sadly, after the exercise was complete) that we had given too much money to each individual, which under-constrained the participants and thus masked their true feelings. This was an honest miscalculation, which I deeply regret. In addition, participants complained of a lack of consistent level of detail among the menu items. Some were very low level and specific, others high level and generic. This required each group to re-define the generic items for their own purposes, and naturally each one did it in their own way. Each menu item was not cleanly disjoint from all the others, leading to a participant to have to choose between items that both possesed some of what they were looking for. In spite of these problems, I consider the exercise a success, for the experience in playing it for future meetings, and, to a lesser extent, for the hard data produced.

Postscript

Finally, I was delighted to have bumped into Jonathan Schwartz in the halls of the Sun building where the meeting was being held. Having known Jonathan from my days at Lighthouse Design, and knowing that deeply understands developers, I felt confident in asking him to stop by the meeting and thank the EG members for donating their time to the Java Community Process. He went one step further and hung out for a little bit collecting data on how well the EG members felt the JCP was working.

Attendees

Comments

• Hi Ed. I liked reading your report. The results of the game astonished me at first as I would have spent my money way differently. I guess that the most distorting influence to a representative outcome (rather than an inappropriately chosen amount of allotted money) might have been the circumstance that the buyers were in most part simulated not by actual JSF customers but rather by JSF (-tool) vendors. I would like to suggest a minor but useful feature: Within a given JSF view, it is most commonly the case that many attributes of components are set to the same values. For example, consider the style- or class- attribute on components of the same type in a portlet application. A view that has 20 labels, each to have it's class attribute set to portlet-section-text or whatever valid portlet style, each configured to have a tool tip with content fetched in the same way etc. A view is cluttered immensely by this reoccurring specification of common default settings on components. People focus much on how facelets reduce the complexity but I think a mechanism for setting attribute defaults for component types might have an even bigger effect. Consider the following sketch. Before:

  <f:view>
  	<x:comp1 header-style="portlet-section-header" inset-style="portlet-section-text" tooltip="#{lookup(me.id)}" value="first" />
  
  	<x:comp1 header-style="portlet-section-header" inset-style="portlet-section-text" tooltip="#{lookup(me.id)}"  value="second"  />
  
  	<x:manyMoreComponents />
  </f:view>
  

  After:

  <x:default attribute="comp1.header-style" value="portlet-section-header" />
  <x:default attribute="comp1.inset-style" value="portlet-section-text" />
  <x:default attribute="comp1.tooltip" value="#{lookup(me.id)}" />
  
  <f:view>
  	<x:comp1 value="first" />
  	<x:comp1 value="second"  />
  	<x:manyMoreComponents />
  </f:view>
  

  Or course, these examples need to be looked at with goodwill. The view content and attribute use is not profuse enough to illustrate the profit of specifying attribute defaults. Also, most components that vendors offer have a host of attributes and being able to set attribute defaults on application-level and page-level is a kind of customization that is easy to add and should make JSF appear even more powerful because one could showcase how impressive rendering results can be achieved with even less code. Last but not least, such a kind of attribute defaulting might also alleviate the need for a dedicated skinning functionality. -- P.S.: a clever customer would only buy declarative renderers and furthering the useability of JSF for templating outside the context of web-applications as this will buy him heaven thereby making them rich enough to buy all other features of all forthcoming releases :D

  Posted by: wtff on May 15, 2007 at 08:09 AM

• BTW, one could also think of this proposal as "server-side style sheets".
  Directives outside of the actual page components that customize the components by setting default for them.

  <x:defaults>
       comp1 {
             header-style: portlet-section-header;
             inset-style: portlet-section-text;
             tooltip: #lookup(me.id)
        }
  </x:defaults>
  

  What's right for the client can't be wrong for the server, right? The stylesheet metaphor might inspire further ideas around attribute defaulting, like inheritance among styles or contextualization of style directives as in h1.div { ... } etc

  Posted by: wtff on May 15, 2007 at 08:33 AM

• I am a JSF customer, and I find the voting to be right in line with my preferences. I agree with the conclusion that of the "expensive" features, zero deploy time--while nice to have--doesn't have the same bang-for-buck as the others. (I assume it not making Table 2 suggests this.) Would be great for those who really want it to be able to seek it out as an extension (JSF-Ext or otherwise), but I'd rather the spec focus on the other biggies.

  On the "Ajax" item- I love the idea of a client-based lifecycle, but I have a problem with allying this feature so closely with Ajax. With Flex and potentially applets (with JavaFX) gaining traction, the spec should, at the very least, have a pluggable client-side architecture that allows different components/component sets to be comprised of non-Javascript entities. For example, the spec should make it possible for an enterprising 3rd party to wrap the entire set of Flex 2 components (now open-source) into JSF counterparts, communicating back and forth using this pluggable client-side architecture. This could be done today, by using a combintion of DynaFaces, Adobe's FABridge JS-Flex bridge, and a little glue code; but it would be great if JSF 2.0 provided extension points making it easier.

  Or, if you prefer, this being a Sun blog :), imagine that once the mean 'n' lean consumer JRE comes out mid '08, a Java.net project that marries JavaFX with JSF comes out, wrapping various rich client-side controls in JSF components that let you keep logic (and bizObjects) back on the server.

  I don't know ... the further these rich technologies come (Flex 2's MXML is a fantastic example of EZ component composition/extension/definition, b.t.w.), the more I wonder how much sense it makes to kill yourself building Ajaxified components like Trees and whatever else in DHTML/Javascript- or, at the very least, to define the JSF spec narrowly enough such that alternatives aren't facilitated.

  Posted by: rogers_reilly on May 15, 2007 at 09:09 AM

• >> On the "Ajax" item- I love the idea of a client-based lifecycle, but I have a problem with allying this feature so closely with Ajax. I fully agree. The JSF spec should be evolved with Ajax in head but shouldn't Ajax written anywhere on it.

  Posted by: wtff on May 15, 2007 at 10:09 AM

• Components, Components, Components!

  Creating components that works in any JSF container is as fun as coding bytecode directly. It is very hard to get ROI on a component unless you are a big company that can create its own component creation framework.

  Posted by: mikaelgrev on May 15, 2007 at 10:18 AM

• As one of the "facilitators" of this process I can say that I thought it was a refreshing change to the normal "sit back and white board it" approach. The process kept all EG members involved. Nice work Ed! -roger (JSF co-spec lead).

  Posted by: rogerk on May 15, 2007 at 11:54 AM

• Better error reporting! In my experience, the Stack Trace from Hell does more to turn off people from JSF than anything else. It is such a relentless productivity killer. I am surprised that it didn't rise to the top instantly. You all have become too good at reading stack traces :-)

  Posted by: cayhorstmann on May 15, 2007 at 09:41 PM

• cay, without a doubt, error *handling* is at the top of people's priorities, but when it came time to bet on what most of us assumed was an implementation detail not an API focus-- we'd vest our dollars elsewhere ;-)

  Posted by: jhook on May 15, 2007 at 09:56 PM

• I'd have bought (in order of priority):

  • Facelets (esp master/client templating)
  • Ajax
  • EZComp (Declarative Rendering might have been included here)
  • Mostly GET
  • Fix state saving

  That's $505. Did I overspend? The only additional items from my list of ideas I'd press for would be:

  • Conversation scope
  • Page Lifecycle ala Shale ViewController
  • Standard method to package and fetch component resource (e.g. images)

  Posted by: rogerkeays on May 16, 2007 at 12:54 AM