The talk I did at QCon SF 2009 is now available at infoq. Only an MP3 download is available, otherwise you’ll have to stream it from the site – but you’ll be missing a lot, as the slides are better than hearing me drone on.
I’ll be presenting a session entitled “Refactoring Databases for fun and profit” with a colleague at this year’s “XP Day 2006”:http://www.xpday.org/. XP Day (not just XP, not just one day…) is run by the long-established (and Olde Bank of England regulars) the “Extreme Tuesday Club”:http://www.xpdeveloper.com/. I attended last year and can highly recommend it to both beginners and seasoned practitioners alike. The conference is very vendor-lite – it is run by practitioners, for practitioners.
Our session will be feeding back experiences of using some specific database refactoring techniques, and will also be presenting a new open source tool for managing database change.
A Tech Lead Manifesto
Overview
I’ve had a chance over the last few years to observe various different types of tech leads. Collated here are my views on what I think makes a successful one.
A Tech Lead Should…
- Ensure the creation of a clear and consistent technical vision for the project which can best result in a successful project
- Ensure all members of the team have a proper understanding of the technical vision
- Ensure that the technical vision updates to reflect new requirements
- Track and resolve issues where the code deviates from the technical vision
- Create an environment in which all members of the team can contribute towards the technical vision
- Understand and address skills gaps in the team which would result in difficulties implementing the technical vision
A Tech Lead Should Not…
- Tell everyone what to do
- Necessarily be the best at everything
- Write no code
- Write all the hard code
I just got this from an old colleague:
Despite all of our many successes, our architect has started making noises to the product management team that pair programming is a waste of money.
Why should he let mountains of academic research and our own project metrics get in the way of his own personal opinions!?!?!
Sometimes I just want to pack up and go home
Now first off, when people start talking in favour of Pair Programming, I tell them two things:
# From what I’ve seen, it’s the most efficient way to transfer skills, reduce “truck factor”:http://www.agileadvice.com/archives/2005/05/truck_factor.html, ensure quality and (say it quietly) stop slacking. It’s also damn hard to get some companies to try it for a number of reasons.
# Read “this Hacknot article(Hacknot – A Critical Look At Some Pair Programming Research)”:http://www.hacknot.info/hacknot/action/showEntry?eid=50 before you start quoting studies.
I don’t happen to agree with the editorial bais of the Hacknot site – my own (and my company’s own) experience has shown that we produce better software more efficiently when pairing. That said the study quoted is clearly flawed for the reasons mentioned. There have been more studies since – one day I should really get round to pulling them all together. The major problem in producing such a study is that I don’t know anyone who would spend the money creating a real world experiment over a long enough period of time to produce conclusive results.
I am however fairly sure that “pairing with a cat”:http://www.hacknot.info/hacknot/action/showEntry?eid=21 yields no benefit over pairing with an alternate programmer.
magpiebrain 