OK, it’s the end of 2006, but at least our development shop can return to Java 1.5 when IBM releases a new version of RAD in the second half of 2006. There exact words from the press release are:

IBM intends to ship a new version of Rational Application Developer in the second half of 2006.

I’m just going to hope for the best here, but realistically I bet the next version of RAD may slip to 2007.

The more interesting statement is:

Full Java 2 Platform, Standard Edition (J2SE) 5.0 support across all offering…

This statement concerns me. They make absolutely no comment on Websphere Portal Server. Currently the boat anchor in our web stack is Websphere Portal Server 5.1. If I’m reading this correctly, they say there going to support Java 1.5 across all their offerings, but they’re not going to release a new version of Portal Server. Hopefully this was just an oversight in marketing.

At least I’ll get a chance to ask some actual IBM Websphere folks in person this week. The first question will be when Portal Server will finally get upgraded to support Java 1.5.

Our organization has been through three wikis now. It started with JSPWiki and moved to PHPNuke and now Confluence. I don’t think our story is all that unusual, but it may be illuminating.

The point of course is developers always need a way to share information on workarounds, configuration, or just some defacto practices like how to notify everyone you’re restarting JBoss on a shared development integration server. Typically there are also a lot of artifacts around individual projects that are helpful to store.

Wikis then solve the typical problem with things like shared drives or email. They’re easy to add content to, they keep revisions, and anyone with a web browser can access them. The typical downside with wikis is that small barriers are enough to defeat them:

• You have to deal with some little markup language. If you cut and paste in something out of Word or an IDE, you can find yourself with a painful bit of editing.
• Since no one owns access to the wiki, the navigation can get pretty screwy and important information can get lost. Self-organizing information architecture can be difficult.
• Once the initial interest in the wiki wanes it faces the possibility of becoming irrelevant because people stop posting things there and revert to email or other ways.

We started the adventure at our company with JSPWiki. It worked better than I expected for while and people posted a good bit to it about Websphere, JBoss, and testing topics. The left-hand navigation got to be a long scrolling menu as the defacto site for linking new pages. Overall after about 18 months there have been 50 or so items posted. We still use it today, but the addition of new content is maybe one or two items a month. A lot more gets passed around via email.

Another group started up a PHPNuke site, which they consider a wiki, about 9 months ago. I actually consider it more of a content management portal, but it was supposed to serve the same purpose as a wiki. It required you to create an account to do anything so it had an extra barrier to entry. Someone posted something new there about two weeks ago and so I logged in to check it out. It was difficult to find since for some reason it didn’t appear on the latest news on the front page. After hunting around in the PHPNuke site I found the real problem. All told there were only eight pieces of actual content, so it was a dead wiki walking.

Finally, I looked into Confluence about four months ago. I setup a trial and then didn’t get back to it, but in that short period of time I liked what I saw. It had email integration, RSS feeds, a simple concept of project sites, and most importantly a WYSIWYG editor allowing for simple cut and paste style posts. Still there was the pain of filling out a small PO to purchase a 25 seat license, so it just didn’t make it to my front burner. And I thought there might be a nice open source one out there that would work better.

Then about a week ago one of our senior developers just asked a very simple question:

Can we just spend the $1200 and buy a Confluence license? I’ll do all the work to set it up.

After all the time spent talking about it, I filled out the PO right then and there. And because it had a 30 day trial we have it up and running already. It appears to be working for us so far, but even if it fails $1200 is a lot cheaper than all the time talking about a solution.

After we’ve spent some time with it I’ll do a follow up post on what we’ve learned.

Listening to a really good podcast by Kathy Sierra on Passionate Users she explained many of her themes on how to make users have more “I rule” experiences. One minor thing she might have gotten wrong is that chess is fun but not funny. As a former high school chess champion I can point to at least one classic chess book that proves chess can indeed be funny:

And if you are a chess player I advise picking up Chess for Tigers.

I got excited today to learn that Practices of an Agile Developer is already shipping. I was given the rare treat of reviewing an earlier draft of the book, and I think it’s a great addition to the Agile canon.

Andy Hunt and Venkat Subramaniam cover about 45 agile practices from Invest In Your Team to Architects Must Write Code. The topics are generally 3-5 pages long and its about 200 pages so you can finish it in a single night.

I mention the single night, because that’s how long it took to read the first draft. It’s just really rare that you get a well written book on exactly the topic you’re most passionate about. There really isn’t a better book covering Agile practices.

Just one example was a practice entitled Warnings Are Really Errors:

Find a way to tell your compiler to treat warnings as errors. If your compiler allows you to fine tune warning reporting levels, turn that knob all the way up so no warnings are ignored.

Such an obvious idea, but like I suspect so many others I had regularly let warnings go figuring, heck they don’t mean anything. Psycologically they always bugged me, but I let it go. It’s really not too different from dropping tests because you’re in a hurry with the idea you’ll get back to them later. Making them actual errors enforces fixing things up front, nice.

My favorite part of the book is the suggested courses of actions in what to implement first as a manager leading your team down an Agile path, but that’s a post for another time.

In a short talk at SD West 2006 Alistair Cockburn described a lot of different office layouts including this technical discussion area:

It would be really nice to setup something like this. Haven’t really had anything like it though since the dotcom days. And back at least a few times people fell asleep on the couches after pulling an all-nighter.