When I read Alfie Kohn's book "Punished by Rewards" a couple of years back it made me rethink some things about employee incentives and more importantly how I talk to my children.
I recommend you read this article as a taster.
Reading Keith Braithwaite's comments on blogging see the XTC wiki made me reflect on why I try to blog.
About a year ago my view was that if bloggers had an opinion on a topic they should join a dialogue on a wiki or yahoo list rather than talk to themselves. However, in the last year I have started to turn my thoughts to writing a book. I whined to Alan that I wanted to get into the habit of writing a little each day and he kindly set me up with this blog.
I know I don't post everyday but it helps me to get into the habit of identifying topics I care about and how to write about them, thinking about style, etc.
I have spent so many years writing software and requirement specs it's really hard to put myself back into my writings.
Sometimes developers are so keen to give their customer working software that they defer work that should be done such as refactoring or unit tests. It's easy to tell yourself a little white lie "I'll do that later" but once you tell your customer that feature is ready, they are going to ask you to work on something new so there's no time to fix it up. Not only that because you turned around that piece of work so quickly, you are setting expectations that it does not take so long to do a proper job. Too many developers assume that as long as the software works the customer is going to be happy. Cutting back on doing a quality job now will slow the team down later.
Test Driven Development is a good way to make sure that you don't cut writing tests. By writing a test and then the code to pass those tests in small steps, you make sure that you have tests for all the code you write. Even when teams use TDD it can be tempting to defer refactoring, the customer never sees the code so they don't know how ugly it is. The point of refactoring is to keep the codebase as small and neat as you can so that it is easy to understand for maintainance and you do not carry dead code that is not used in your target application. You are not doing your customer a favour by skipping refactoring.
As a software developer, it is your responsibility and no one else's to write maintainable and good quality code. Your customer is relying on you to write software to an appropriate standard.
How would you feel if a gas engineer installed a central heating system that heated your home just fine but when maintainance was required needed some walls to be knocked down for access to the boiler?
Today I drove past a sign to Greenham, site of womens peace protests against the siting of nuclear weapons at the airbase there at the start of the 80's. I was at "Embrace the Base" in 1982, an amazing event where we formed a human chain miles long around the site see here for a report of that day.
Apologies for gushing but I just got home from attending the 3rd Retrospective Facilitators Gathering in Austria. I have returned feeling energised and full of new ideas to work on!
It was a great honour to meet so many wonderful people, including Norm Kerth author of the "Project Retrospectives" book that has helped so many of us learn how to facilitate retrospectives.
The program was organised as a five day Open Space .
Highlights for me were:
looking though Frowin Fajtak's photo portfolio of retrospective exercises,
hearing how to define project Charters from III,
learning about how to create project maps from Ainsley Nies - a technique we tried for ourselves in the farewell session.