When no one can run the software

naked capitalism: Another Lehman Mess: No One Can Run the Software:

I have no idea whether this estimate is still valid, but back in the days when I was working with O’Connor & Associates, the head of technology (and O’Connor had a well run technology operation) said the cost of documenting software (as in having the developers write up what they did in sufficient detail so a third party could maintain the it) was an additional 20%. It was very difficult to get traders to pay for it, ironically not so much for the hard dollar costs, but the fact that IT was resource constrained. The idea that the coders would spend a lot of time on leaving a paper trail, rather than getting to a business center’s urgent need, was a hard sell.

But Lehman illustrates what happens when you do what most places do, and skip documentation.

What is ECM-SOA?

EdLovesJava: ECM-SOA With Agile Attitude:

The first challenge is to think of our tooling as not a custom application, but more as a set of adaptable services, applications and integrations. This requires a change of thought.

Our previous efforts were to drop a monolithic application called a Content Manager into the middle of things, and then propose to change the business process around this application, ostensibly obsoleting the existing applications and ad-hoc processing to customizations within this new application.

During our previous attempt, we underwent a lengthy analysis phase and generated a 500 page requirements document detailing taxonomies, content types, work flows and templates that would solve our content management (web content management) needs. We then spent lots of time and treasure implementing these requirements. In the end, we built some of the requirements taking far longer and far more resources than anticipated, and we found that most the requirements and subsequently most of the customizations we built were wrong. The heroic content managers and brand managers made it work anyway, developing more ad-hoc, complicated and time consuming steps around yet another application that was supposed to help them. This story is not unique.

We must shift our processes as much as our technology. We are focusing on smaller efforts, more agility and more feedback and move away from 500 page requirements documents. To do this successfully, our architecture also needs to be agile and amenable to change. Our architecture must be a framework to grow on: to grow useful services, and to grow and integrate with useful applications. It must follow user demand that learns from using and refining our processes and tools.

Javascript links for September 8, 2009

Ian J Cottee: Rhino on OS X Leopard

peter.michaux.ca: Server-Side JavaScript with Rhino and Jetty

gorilla3d.com: Programming Java With JavaScript

Steve Yegge: Code’s Worst Enemy

John Resig: Bringing the Browser to the Server (hmmm, jQuery on Rhino?)

YouTube: Google I/O 2008: Steve Yegge on Server Side JavaScript (transcript and slide links):

benne: On-the-fly JavaScript syntax checking in Emacs

Patrick Hunlock: Essential Javascript (nice tutorial)

The UNIX Way

Kas Thomas of CMS Watch riffs on “The UNIX Way”, principals summarized by Mike Gancarz:

1. Small is beautiful.
2. Make each program do one thing well.
3. Build a prototype as soon as possible.
4. Choose portability over efficiency.
5. Store data in flat text files.
6. Use software leverage to your advantage.
7. Use shell scripts to increase leverage and portability.
8. Avoid captive user interfaces.
9. Make every program a filter

Read the whole piece.

cURLing with Alfresco’s and Google’s Data APIs

Jeff Potts: Curl up with a good web script (interacting with Alfresco’s Document Manager via CMIS and Atom)

Google Data APIs: Using cURL to interact with Google Data services

Bonus: commandlinefu.com: Update twitter via curl as Function