I’m very keen on going to see what cross over there is between domain modelling for general purpose software systems and content modelling for content managed solutions, a particularly interesting area for me at the moment.

Hope to see you there

This is me with the mac waiting for QCon London’s 2008 keynote by Kent Beck on Trends in Agile Development to kick off. QCon 2009 had notably fewer attendees than 2008. However, not knowing the exact numbers, it was still a large turnout for any technology based conference.

Did I enjoy QCon? Yes and No. For me it wasn’t as good at 2008. I thought the best talks were on Wednesday and Thursday, and I couldn’t make Thursday. However, I was co-host on the Financial Track. So although I really enjoyed the talks we put together there (See Kirk Wylie post on the track), you just have to miss some stuff going on in the other parallel streams.

Last year, when I was free from track host responsibilities, I’d duck and dive from one session to the next. This year, delegates were doing this in a more informed way through the power of twitter. Boy this was strange thing to behold. Delegates in all the sessions were tweeting away against #qcon as the speakers presented and listening in through tools like TweetChat. The net result was that speakers were being rated in real-time.

So what? Well if your listening and thinking of ducking out to a session and learn then that its boring or too high level, you don’t move. The reverse is true of course. The TDD session was packing up and lemming effect took hold. Ah, you think, if that’s packing up, I should be there as well. So, off you go, taking a few others with you.

It’s funny and unnerving I’m sure for a speaker to see 10 people suddenly stand up in unison and leave because of a well constructed tweet! Again, the reverse holds. On our financial track we had the head of hedge fund talk about computational finance and how they operate (fascinating talk but you just had to be there really, you simply don’t get it from the slides ). Hedge fund guys DO NOT do this. So I, apologies to other speakers, crafted a cunning tweet letting people know that this talk was also NOT being filmed. And it wasn’t by the way. Two minutes later, I kid you not people, 10 people joined the talk, and another 3-4 after that. Twitter, you gotta love it.

Unfortunately, I could only attend QCon on Wednesday. But I did sneak in a cheeky speaker dinner on Tuesday night. There I caught up with my long time friend and early mentor, Linda Rising and was unleashed to the full on madness that is Dan North. Also, I managed to slip in a few cheeky beers at the Wednesday night QCon party. And of course, the conversations over food and drink are so much more interesting and involved than the ones you partake in during the day…

I’ll definitely be going next year.

So it’s that time of the year again. QCon London is back and I’m co-hosting the Architectures in Financial Applications track with Alexis.

I’m trying something different this year. I’ve set up a twitter hashtag called #qconfinance so that the twitters in (and not in) the audience can post questions that we can respond to in the breaks and even after the conference if we run out of time. Interesting to see how this works.

For twitter folks, TweetChat is a great way to view all tweets in a chatroom fashion. The hashtag, with the #, is the name of the chat room. Simple! Hopefully see you in there…

It was during this time that I stumbled across the Roach Motel. For cockroach infestations, get the roach motel (it was actually a mini-hotel with poison in it), place it in the middle of the room, and overnight the roaches entered two-by-two. Nice!

Roaches check in — but they don’t check out!

This is exactly what happens to knowledge (documents) when you just add stuff without thinking about the 1) target audience and 2) how they are going to find and take value from the knowledge you’ve supposedly just contributed. Wikis can quickly become central to everything you do, holding critical information about the company, the projects you participate in, and the people you work with. But when you start hearing things like:

• Where should I put this document?
• I don’t put things in the wiki because I’ll never find them again!
• Damn, this wiki is just too big

You’re wiki is breaking.

Worst still, I was in a meeting when Bill said to Ted, “What’s our expense policy?” It’s in the wiki Ted responds, slightly miffed for having to say the words, it’s in the wiki. Bill sighs, “I knew you were going to say that, going in…”. That little exchange confirmed it for me, the wiki and/or or it usage was well and truly broken.

So fix it!

Well, it’s not that simple. But before we address that let’s agree on the problem first. There are two key types of knowledge: tacit and explicit. Tacit knowledge is know-how that typically resides in the minds of the few, the experts. Explicit knowledge is know-what and is the scaffolding upon which to hang tacit knowledge. Both are critical but tacit knowledge is the one that tends to leave your company when people resign, go on holiday, move projects, change job role, and so on. Wikis are a means to capture, store and make accessible tacit knowledge. Wikis are all about knowledge transfer.

However, I’ve found that only a few people invest in wikis. Assuming everyone in the wiki is withholding tacit knowledge, an unbalanced wiki is one where the number of leeches (consumers) vastly outnumber the seeders (producers). But this is preferably over a broken wiki that is awash with partial seeders. A partial seeder is even worse than a leech because they actively damage the knowledge space but think that they are enhancing it. Here are some of the characteristics of a partial seeder:

• Come back later: Create an empty page as a placeholder and six months later its still empty.
• Random page naming: A Study to Determine Site Performance – the resulting URLs for page names like this can be is ugly and non-intuitive.
• Lack of Formatting: Create pages that are pure text without using the available wiki text formatting.
• Crappy content: Because its not a Word document, because I’m in a hurry, because its a wiki, because there is not review process, no need to think. Let’s write crap and go!,
• No pictures: I can’t tell you how many times a good picture, on a page, would have saved me many valuable minutes/hours.
• No text: A picture is a thousands words, I get it. But few words to annotate a picture would be nice, to set the scene. Again, another symptom of crappy content and my time is more important that yours.
• And the list goes on…. (love to hear some of yours…)

Value your audience

If I write something for someone else’s benefit, I tend to invest at least 5 minutes of my time (writing) for every minute of your (reading). So if 5 people read a 1 minute article, I break even. Anymore, I’m adding significant value, particularly if those readers are customers, employees and/or work colleagues. Consider the reverse scenario. I invest 1 minute of my time to write a document that takes every reader 5 minutes to decipher. The more people that read it, collectively the more of time I’ll have wasted of theirs. For internal company communication, that’s not good. An extra 2 minutes putting in a picture in place, another minute refining the content and finally a minute to format the text, well, waste very quickly becomes value. Let’s do the maths. In terms of company time, if that document targetted 40 people, you just gone from 200 minutes (40×5) to 40 minutes (40×1) of reading by investing an additional 4 minutes of your time writing.

Are you a partial seeder?

I think we are all prone to be partial seeders. The trick is to stop yourself. Don’t push crappy content into the wiki. Report crappy content back to author and get them to fix it up if its that bad, or tweak it yourself if its a simple fix. Just because it’s easy to add content to the wiki, doesn’t mean it has to be crappy. Otherwise, the wiki quickly moves from being a knowledge source to a knowledge sink. At that point, it would be better just to switch it off rather than continue on regardless.

Well, that seemed easy. So I tried it out. Hmm, that works. Then I re-watched the ‘Introduction to Git’ video above. Hey presto, from git-to-god in six months. Impressive. I still don’t like video, can’t put my finger on it, but I love the Git. And to those people that brought us the Git and a big thank you to you.

What is the Git? Git is a fast distributed revision control system. Now I use the Git religiously. Not just for my personal coding projects, but for the documents I write, the web-sites I build, people I share knowledge with, and so on. But why do I like Git, a few things really.

Firstly, I tend to operate out of directories a lot and need to version control everything under it. What I don’t want to have to do is create an artificial master copy on a centralised server and have to periodically sync up to that. Pointless. Instead I just want everything I need to be available from within my working area – my directory.

Secondly, branching and the management of branches must be brainless activity. Git embraces and encourages branching. After reading the git tutorial I was shocked at just how easy it is to work with branches. There is just no other way of working for me. Branching in subversion is harder and hence less appealing to me, so that’s probably why I didn’t use it as much as I’d liked/should have.

Thirdly, local commits. I can commit without access to a centralised server. There is NO centralised server. Instead you have a network of peers. No need to distribute/cluster a central repository. Distributed repositories are the norm, not the exception. There is no single-point of failure that you have with subversion, instead, the risk is spread amongst your peers.

Finally, simplicity. Once you’re happy working with branches locally, you can push and pull information to and from your peers’ branches. The syntax is clear and concise. There is not difference really to what you’re accustomed to working locally.

The problem with Git and distributed revision control systems like it is industry take up. Will the build systems such as Ant and Maven, the IDEs such as Visual Studio, IntelliJ and Eclipse, and so on support the Git. I think this is happening but cannot report conclusively on the current status. However, I am starting to see many more open source projects start out with the GIT and other migrating over. Also for web site development, where you try out new stuff, roll forward, roll back, compare and contrast, numerous different solutions, Git and its easy branching solution is a great tool.

Finally, a commercial example. I use a Groove. It’s a collaboration tool primarily used for sharing documents. It has a proprietary algorithm for the effective sync’ing of large amounts of data across a network. It also is a commercial product and so there are lots of features such instant messaging, calendaring, discussions, sharepoint integration and organising stuff. However, for me, all that is redundant. All I need is fast distributed, file-sharing.

The problem with Groove is that is breaks easily (admittedly the pre Microsoft Groove 2007 version). I’ve had to install it many times in the past and that takes time. When I change machines, I have to re-install it. When it starts crashing, I have to re-install it. The sych’ing between my peers has been problematic, to the point where we are asking each other whether you have the latest update. That’s not good. Given that I only use Groove for file sharing, I believe Git would be a much better and reliable solution going forwards. It also has the added benefit of being cross platform.

Mac vs PC – Transformers

Successful teams value planning over plans. However, things are really broken when the reverse is true. We’ve all been there before, trapped within the mother of all project plans. You don’t need a sixth sense to see what’s coming – we see dead projects! Jeff Goldblum in Jurassic Park sums up beautifully the typical phases within a plan-only project:

“Ooh, aah, that’s how it always starts, and then later the running and screaming… “

About eight years ago I joined a project to seed Java knowledge. The team was new to both the language and object technology. After an initial requirements discovery phase and some preliminary high level designs, the project manager called a team meeting to discuss the plan. We all sat down ready to start planning. I love planning sessions. Instead, in true Blue Peter fashion, out came a completed Gnatt chart that the project manager “had prepared earlier”. My heart sank as he handed out the “final” plan with all the final steps to success. Upon closer inspection, things were much worse than I had first feared. Armed with the initial designs, add a generous sprinkling of Java for Dummies, and our friendly neighbourhood project manager added every class as a line item within the plan.

Then, he did it. Oh boy, did he do it. He asked us to estimate each class on his project plan. So for the AbstractDataFactory class, 1 day, StringUtils, 2 days. And so it began, every day at 4pm GMT, we had a status meeting where each team member provided an update on % Complete for every class that they were responsible for. After 3 of these 2 hour daily meetings the team rebelled. Our project manager was suffering from a bad dose of plan-blindness. He could NOT see past the plan. The plan was the deliverable. The project been relegated to being the dark horse of the family. We no longer planning. Am pretty awful place to be really.

Fruitless discussions between the team and the project manager brought about no change. Time was a premium so we made a decision. Project over plan we agreed. The team started scheming. From our perspective, the plan was total project waste. I won’t even tell you what happened to the plan when we re-factored the code base on day two. So we looked at all the classes on the plan, wrote a simple application that sent an email that bumped along our % complete to successfully deliver the plan. The email basically told our project manager want he wanted to hear, delivered the plan, and immediately re-claimed a valuable 2 hours per day per developer. We then set about successfully delivering the project.

So what? First of all, I’m not saying you don’t need a plan, but the plan is not as valuable as the act of planning. Secondly, continuous planning is essential. If you sat down with your team now, handed them a piece of paper and asked the following questions:

1. What is your next deliverable?
2. When is it due?
3. Are you on track?

If your team members come back with different answers, something is broken. Finally, some people are good programmers, others are not. Same for planning. Some people are just not wired up to plan ahead and prefer to just do it. That’s not a big deal but you just need to be aware of that and encourage them to participate in planning sessions.

Take a look at the above. I regularly take snapshots of my Windows environment. You just can’t be too careful. On the 12th December I realised that Microsoft Groove was failing and my printer drivers were bombing out. So I rolled back to the November 25th snapshot and found the same thing was happening there. Rolling back further to November 5th I find that everything was working as expected. I create another snapshot based off the 5th November Windows environment, call it 12th Dec Safe and start trouble shooting. After a few hours of tinkering I work out its XP Service Pack 3 that screwed everything up.

I’m finding plenty of problems on the web with XP Service Pack 3 and Groove so I’m continuing to troubleshoot against the XP Service Pack 3 snapshot. However, in the meantime, when I need to work with Groove and Printers I continue to use Windows against my 12th Dec Safe snapshot. When I fix the XP Service Pack 3 problem I’ll be able to apply it to my safe version.

That is just a great way to work with Windows, don’t you think…

But I have, just for fun, been taking a look at Apache Sling and have just got as far as installing it. Baby steps…