Thoughts from a Thirsty Bear

" It is not the critic who counts; not the man who points out how the strong man stumbles, or where the doer of deeds could have done them better. The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood; who strives valiantly; who errs, who comes short again and again, because there is no effort without error and shortcoming; but who does actually strive to do the deeds; who knows great enthusiasms, the great devotions; who spends himself in a worthy cause; who at the best knows in the end the triumph of high achievement, and who at the worst, if he fails, at least fails while daring greatly, so that his place shall never be with those cold and timid souls who neither know victory nor defeat. " P Theodore Roosevelt,   Paris ,  23 April, 1910 excerpt from the speech "Citizenship In A Republic"

Old Russian Proverb: If you chase two rabbits you will not catch either one

(If anyone would like to claim this is their work, I am more than happy to recognise the fact - credit where credit's due. Just drop me a line)

Currently it seems trendy to say that your team no longer estimates. Or that estimating work is pointless (pointless? Geddit? oh never mind....). Hell, even I have said similar on Twitter . So estimation is finally dead. Hurrah! No more picking meaningless numbers out of thin air when you really have no idea how long something will take. Finally we are rid of a process that is demonstrably flawed . Except...is that a twitch I see from the lifeless corpse? I do believe it is! There will always be times when it is genuinely useful to answer questions such as "Will we be able to show our new product at the April trade show?". Or "Which quarter do we need to start ramping up our marketing for the new feature?". All of which require estimates. Not necessarily to-the-day accurate estimates, but still estimates. Even teams who claim not to estimate are finding that it is useful to make a judgement call - dare we call it an estimate - on the size of a requirement ...

Hurrah! I have earned another piece of paper (with distinction, no less :-) )! This time for completing the excellent Functional Programming with Scala course run by Martin Odersky and Coursera. I have touched on functional programming before, back in the days when I used to write XSLT for a mashup engine, but this course really helped open my eyes to what the underlying principles are. Not to mention forcing me to reassess the level of test-driven you apply to the new techniques. Now the journey really begins!

“The tools we use have a profound (and devious!) influence on our thinking habits, and, therefore, on our thinking abilities. ”,  Edsger W.Dijkstra ...or in other words... "If you already have a hammer, it is very tempting to treat everything as a nail" My views on using electronic tracking tools  are already fairly well known . But another area that creates a huge impact is the choice of version control system. Using the right software will help your project deliver quickly and efficiently. Choose the wrong one, and the project will be nobbled by unnecessary, damaging and sometimes downright dangerous processes and maintenance overheads right from the start.  In order to avoid the trap highlighted by Dijkstra, it is essential to match the tool to the way you develop and not the other way around .  Let’s consider a fairly typical, highly productive and successful team. In my experience they tend to follow a fairly well defined pattern of working:...

Team: “ Coach! Coach! This agile process stuff you sold us doesn’t work! ” Coach: “ Did you build working software regularly? ” Team: “ No, it was too difficult. ” Coach: “ Did you extend your definition of Done as far as you could? ” Team: “ No, it was too difficult. ” Coach: “ Did you make quality part of your process? ” Team: “ No, it was too difficult. ” Coach: “ Did you review what you were doing at all? ” Team: “ Yes, but we didn’t like what we discovered, so we ignored it. ” Coach: “ So are you absolutely sure it was the agile process that caused you to fail? ” Team: “ Oh yes, absolutely…. ” Coach: " <sigh> " * honest....