Blind Man’s Bluff

The project I am on could easily be likened to one of the popular team challenges on Survivor. Frequently the two tribes are presented with a scattered set of puzzle pieces that must be collected and then assembled. The catch is that all but one team member is blindfolded, and the sighted team member must verbally guide his or her team to each piece and back to the collection point.

In my current engagement we, the consultants, are tasked with mentoring the client on using the Rational Unified Process (RUP) as the methodology for creating new applications. The push to adopt RUP came from the top down, so there are varying degrees of acceptance among the client resources on the various RUP-enabled teams. So far the work has consisted of heated discussions about concepts and language, with lengthy digressions into document formatting battles. In my case there is one team member who is fighting every new concept, every iteration over material, every bit of the new direction. It is massively frustrating.

Up until now we have had the charter to produce the analysis and design models for the application, and were expecting to be tasked with providing some form of post-design support to the implementation team(s). Yesterday we got word of a change in policy that is headed our way. The business management team is concerned that having the consultants lead the design effort while mentoring the employees won’t transfer enough practical knowledge to the employees. So the new direction that is being considered is consultants leading and participating in analysis activites only, while mentoring the client team through design.

Mentoring design?

Should this approach be adopted my days will consist of sitting in a chair behind the client resource telling them where to click, what to type, and how to complete the artifact at hand. Instead of doing the design with them, I’ll be reduced to an entirely hands off "blind man’s bluff" style of interaction. There is a challenge here, do I know the design techniques well enough to teach unwilling and poorly motivated resources? Can I find ways of motivating them to use new concepts and tools, when they disagree that there is a need for a new approach altogether?

And the largest challenge of all, can I motivate myself to stay here and relinquish an active part in the creation of the design? Or are my needs as a professional met only when I have an active part in the production of my assigned design goals?

Filed under: Project Management

Updating My OS

I am preparing to upgrade my primary computer, a Macintosh Powerbook G4, to Tiger aka Mac OS X 10.4. When I made the upgrade from Jaguar (10.2.8) to Panther (10.3) I inadvertently lost all the web and java related development software that was installed in the /usr/local directory structure.

On that occasion I made use of the archive and install feature, which worked flawlessly. It was my own ignorance of the process that caused the loss of my files. This time, being forewarned, I’ll be archive the /usr/local contents, and a couple of other directory trees before starting the install.

The real trick will be getting all the files back into place afterwards.

Filed under: Mac OS X

Hibernation

In an effort to learn the layered framework in place at my current client I am constructing an application of my own. It won’t be very complex in terms of functionality that the user sees, but it will span several new (to me) technologies.

Starting at the bottom with the database and persistence layer I am diving into hibernate again. Over the winter I read the excellent “Hibernate: A Developers Handbook” as a way of getting my feet wet. Today I was able to reconstruct the knowledge gained and rapidly put together several mapping (hbm.xml) files. Using some nifty Ant targets possible through the tools extension to hibernate I was able to generate not only the data access objects (DAO) but also the database schema itself. Make a change to the mapping and it is a simple thing to regenerate both.

I probably won’t regenerate the java code again, now that I’m happy with the basic structure of the DAO. The HBM2Java utility wants to make the classes serializable; which isn’t necessarily a bad thing, after all you may want to pass the object around in your http session. However, I’m still learning Java and all of its intricacies; messing around with the required setup of UUIDs is more than I want to take on. (Heck, I’m not even sure if I understand the process of setting the UUID.)

Next up will be the application interface layer. This will allow me to explore Java Server Faces (JSF) and give me a way to test out the hibernate stuff at the bottom. I’ll fill in the middle with Spring later.

Filed under: Hibernate