I had a comment lodged on an older article recently. The poster was complaining about the poor quality of the JWebFit sub-project of JWebUnit In particular, he was complaining about how it meant their project wasn’t delivered on time. There’s an anti-pattern here.
First, I’ll acknowledge that the JWebFit documentation is very poor. In fact, I did, in the third paragraph. However: it’s never been officially released in any way – it’s just some source you can grab with JWebUnit. If that’s not a sign saying “Here be Dragons”, then nothing is. You can’t say you weren’t warned!
The problem here is that the team in question decided to learn how to use a highly experimental tool in the context of a time-sensitive project. Quite possibly, they’d shortened the amount of time available due to perceived (and not proven) benefits to be gained from the tool. They then complain about how their mistake meant that their project was late.
I will be blunt: You should not try to learn something on a time-sensitive project. Or, more accurately, you should watch how much time you invest in learning carefully, and apply risk management principles.
If something will, say, save you up to 10 days (if it works), and you think you’ve only got a 10% chance of learning it quickly, you shouldn’t spend more than 1 day learning it. Spending more is a bad investment decision – even if you learn it in less than 10 days, and it saves you the whole 10 days predicted. Spending extensive time learning something in order to save time is just tossing good time after bad, so to speak.
General learning and experimentation should be done during quiet period or slack times. And good management should ensure that there is sufficient quiet periods to allow learning and experimentation.
Oh, and if you’ve got a problem with JWebFit, contact some of the people listed at here