Making a Decision on Confluence

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.

Chess For Tigers

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.

Practices of an Agile Developer is Out

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.

Whiteboard Plus Couches

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.

Null Object Pattern For Avoiding Null Checks

I’ve had it on my todo list for a while to go ahead and look into the Null Object pattern. I vaguely recalled that it allowed you to return a null object and not have to actually test for things like:

if (employee != null && employee.isCurrent()) {
	employee.promoteOneLevel();
}

I see this all through a lot of java code to avoid the dreaded NullPointerExceptions (NPE). If a Null Object can clean up this sort of thing I’m all for it.

Essentially the trick is to implement a do nothing class like NullEmployee that implements the Employee interface, but all of its methods do nothing. In the case of isCurrent() in Employee, you just have the NullEmployee.isCurrent() method always return false. Pretty simple really.

I’m glossing over the details really and I need to spend a bit of time doing some more implementations. You can find more about it by Bobby Woolf, Martin Fowler, and Joshua Kerievsky.