Firing squad

I think we should take the “Web Services” label into the jailyard, strap on a blindfold, give it a last cigarette, and shoot it. It doesn’t mean much any more, and to the extent that it does, it’s misleading: WS-* doesn’t have much of the Web about it. I don’t have a proposal for a new name for the WS-* style; sorry, but I just don’t care.

From Tim Bray, Styles: Beyond WS and REST.

The Wrong Questions

Walking around the office this last week, I've begun to notice some things I've forgotten about large bureaucracies built around IT projects. Everyone has great answers, but they're answering the wrong questions.

A couple of examples. We're collocated within a division who manage the development and deployment of large projects within the company. Walking through the office last week I saw a large poster of the "Rational Unified Process - Process Made Practical". Now I've never developed under any Rational process (or tools for that matter), but the idea of something that calls itself the "Unified Process" (complete with caps) struck fear in my heart.

In a previous role, we had the experience of receiving several functional requirements specifications that were not suitable to develop from. They missed several key requirements, did not accurately describe the current system and contained lots of diagrams that were nothing more that pretty pictures. One of these specs was a 30-odd page Word file that when distilled contained a page and a half of requirements in bullet point form.

Now, from a business point of view I'm sure these specs were of value, but for their intended purpose they were of little. The problem was, the documents were produced within a process that did not take into account their value to development, only on their adherence to documentation standards. In one case, the requirements had not been gathered from the customers, and the touch points with the function and capabilities of the current system had not been checked with those who knew it best. The document was derived in complete isolation, from a higher level document alone.

Now I don't think that anyone truly believes that we know how to develop software. Those of us who practice XP would like to think that agile is the way and the light. I believe it's a great step forward - and a step that practices self review and the infamous continuous improvement - but it may not be the best way to develop all software.

All in all I have the sinking feeling that there are lots of people are all busy doing a wonderful job that contributes little to the effective delivery of a software project. There are lots of great answers, but the questions being asked are not the ones that should be.

You know you have problems when...

• Your classes are over 5000 lines long.
• You compare your class to three JDK classes.
• You incorporate transaction management, path management, file management, connection & URL semantics in a single class.
• Your class-level javadoc is 100 lines long.
• You use a version of commons httpclient that has bugs parsing URLs with ports & is incompatible with the latest release.

Also known as WebdavResource. Why this sort of code continues to be written is bizarre.

Update. As James has pointed out in the comments, editing your blog over a modem when you cannot spell is not good. I've never had a good experience with slide, and none of my recent experiences is any better.