Adult Behavior on Projects - Article Review

The article "Perspective: Adult Behavior on Projects" by Tim Lister on The Atlantic Systems Guild, hits home a couple of nice points.

1. All of us who work under the yoke of a CMM-I environment feel the burden of process and documentation; and we hear wonderful things about the Agile philosophies that are taking firm root among IT professionals. There is a CMM digram that shows risks diminishing as an organization's maturity level increases (see here). It is a laughable notion, as in the IT field, if one thing is certain, it is uncertainty (i.e. risk). Also, a risk is a risk, however well you plan/document and monitor/control it. You can only mitigate risk, not completely avoid it!
2. The best way to mitigate a risk is to plug away at it as soon as it is detected. Small software engineering iterations are the key. Agile methods are successful precisely for this reason - they have inbuilt tight iterations.
3. Risk management is project management for adults - is an eloquent way to put it! All the PMI theory is well and good, but risk management is the one skill good project managers have in spades. Ability to manage risk on IT/Software projects is what separates the men from the boys!

Of course, with all talk of Agile, why does the Volere Requirements Template (authored by principals of the Atlantic Systems Guild) look & feel so cumbersome? :-)

JAX-RPC, Java SOAP Stack, et al

As I was researching JAX-RPC, JAX-WS and the Java SOAP stack, i came across a lively debate on Steve Loughran and Edmund Smith's paper ("Rethinking the Java SOAP Stack"). The paper roundly criticized JAX-RPC (which was recently renamed to JAX-WS) for being ill-designed for the following reasons succinnctly summed up in Floyd Marinescu's Blog as follows:

1) The object / XML impedance mismatch. The JAX-RPC practice of mapping XML documents to Java objects as object to XML mappin (O/X) mapping and proceeded through a number of detailed examples of how mapping XML constructs to Java objects is not possible.
2) SOAP is not just RPC. The authors show that synchronous and RPC-styled communications don't work well as content becomes larger and network latencies increase.
3) SOAP is not RMI. JAX-RPC is criticized for attempting to provide an identical programming model to RMI:
4) WSDL: an extra complication. The authors assert that WSDL is too complex, and that typical ways WSDL is used discourages contract-driven development.

Richard Monson-Haefel, Don Box and Joseph B. Ottinger blogged agreement with Steve Loughran and Edmund Smith's paper , but Val blogged disagreement that pointed to the following quote from JAX-WS spec lead Marc Hedley that XML document manipulation is possible with JAX-WS.

However the JAX-WS EG recognized that in some (or many, depending on your perspective) cases working at the XML layer is useful/desirable and so we added a couple of XML-centric APIs that completely bypass the XML<->Object layer of the stack: Dispatch and Provider .

Dispatch is the client side API and uses the generic functionality introduced in J2SE 5.0 to offer an API that allows the developer to choose their abstraction. Developers can work with entire messages or message payloads either using XML APIs or using pre-cooked JAXB classes...

...The Provider interface is the server side couterpart to Dispatch

Steve Loughran further clarified his stance and countered Marc Hedley with the following comments on Floyd Marinescu's Blog

"Personally, I don't think having a 'raw xml' option as a get-out clause is sufficient. Not if the main thrust of the API is "our runtime will magically generate XSD and WSDL from your java classes, solve all interop problems and let you make blocking RPC calls to very distant sites.

RPC is the wrong paradigm for long haul connectivity, pure and simple. Its OK on a single machine, workable on a LAN, great on InfiniBand, but not the right way for say, a laptop, to invoke a web service while it roams round a building with patchy WLAN coverage."

An additional discussion can be found here.