Ed Burns's Blog

May 2007 Archives

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

Testing Ajax Apps with JUnit

JavaOne is practically here, so I thought I'd give a preview of one of the sessions I'm on next week. This one is close to my heart, BOF 6825 Testing Web 2.0 Features, Using Real-World Applications. I'll be talking about using The Mozilla Control Program (MCP) to write an automated test that exercise an Ajax application. Big deal, right? Well, yes because MCP enables you to make assertions about the actual Ajax transactions, and also allows you to access the browser DOM using the plain old W3C DOM API in Java.

To make this easy, I've recorded an Elluminate screencast showing MCP in action testing the Dynamic Faces and jMaki sample application. If you're a Sun employee and you choose not to view this screencast just because I'm making you use JavaWebStart to view it, please tell me so I can report you to the "eating our own dogfood" police.

To view the screencast, click here.

This work is licensed under a Creative Commons License.