Extreme Programming.

The spoke has a short post on extreme programming.  Its been a long time since I have been a real programmer, and was probably never an extreme one by any definition, however I have managed my share of development projects and a few things appealed to me in this report.

Developer bids for work: developers in the team bid for tasks. Lowest bid wins and gets the job. 

This is a very cool motivational tool, if you have the right team and culture.

Work in pairs

This is a new one on me, although I have done some of my best work when working in pairs I have never seen it formally laid out like this as part of a methodology.  The overhead cost is considerable at first glance; it would be interesting to see the overall effect on lifecycle cost though.

Work in pairs: but the most experienced one does not drive the keyboard. He/she watches the other one and makes comments

Lies: two developers will be more candid about the prospects for the development. They are also better able to negotiate deadlines and features and less inclined to lie about the situation.

Blame: it is harder to blame two people for getting something wrong. And they will be better able to defend themselves.

Crucial: no one person can be crucial to the development. Rotate the pairs so that expertise is spread around the developers.

Building Systems

This is all about the daily build concept.  I came home with this one a couple of Tech-EDs ago and my dev team at the time were sceptical however they gave it a go and it worked out great.  In fact the approach they took was really pretty impressive.  They were working on a web application using IIS and Exchange accessed via WebDAV and ADO.  They setup an automated system that allowed each person to have their own work in progress system running live on the same system.  Each night they checked in any code they thought was ready for the rest of the team to test and this went live in a shared environment on a test server.  Each night any code that had been tested by the dev team was made available in a semi-production environment.  The old code from previous days was also available live and could be accessed just with a different URL, to test regressions.  The whole system was automated and very easy to use and resulted in very rapid development and lots of early feedback from the users of the semi-production system, who used it live, to run a major programme, but were mainly friendly IT guys themselves who did not mind the odd glitch.

Design in the test:

write the test specs first. Test everything. All coded paths. Automate your tests. Make the testing easy, so you do it lots.

Daily Build: Build regularly.

But not every day perhaps. If someone breaks the build process they must mend it. Make running versions with limited functionality. The deploy process is part of the build and should be similarly automated. Anything which takes more than 10 minutes to build is probably worth looking at.