If you came here from TechEd Bloggers looking for stuff about Smart devices or Visual Studio it is all here. Just lower down......
One of the lovely things about TechEd is that you get the really experienced practitioners giving talks about the stuff they do for a living. And these guys have been there and done it enough to make the complex stuff sound simple and common sense, so that at the end of the talk you really do feel that you know the subject. And they have a real enthusiasm for what they are talking about, which is great to pick up on.
I went to a talk about Extreme Programming and left with a feeling that now I do get quite a bit of it. So, with apologies to Jan-Erik Sandberg, here is my take on what he had to say. In as few words as possible:
Extreme Programming
Magic bullet: not. Will make programs better , but does not solve every problem. Does not speed things up, but the solution will be better and the team will be happier. Fun.
Testing: Testing comes first. First, first first.
Iteration: Iteration is good. Successive versions of the project are produced with increasing functionality over time.
Customer: is part of the process.
Building the Team
Small teams: no more than 10-12 members for best results. May not be suitable for very large projects.
No wimps: people who are afraid to spend time discussing what they are doing are not good choices for team members.
No prima donnas: people who insist on doing it their way are even worse choices
Set code standards: Entire team agrees on how the code is to be written and formatted. No one person owns any part of the code, so everyone should be able to work on any part.
Doing the Job
Specification as a story: get the spec. from the customer as a story which describes a deliverable. Make the customer sign the story (I love that)
Developer bids for work: developers in the team bid for tasks. Lowest bid wins and gets the job.
Don’t document code: if the code is designed right the need for documentation is minimal. If you have to put effort into describing what something does, it does it the wrong way.
Working in Pairs
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
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.
Refactoring: Changing the arrangement of components and messages is something that you should do as your understanding of the problem improves. With good tools you can do this regularly. And you should.
Safe Source: keep your code safe. No need to lock code with certain developers, since everybody “owns” the code base. But make sure you don’t lose it.
There is certainly more to extreme programming than just this lot, but it should get you thinking. Personally, I've been doing quite a few of these things anyway because they seem like common sense to me, but taken as a whole they look pretty pwerful and you should take them on board next time you pick up a contract....
If I’ve missed anything – let me know…..
For pictures of TechEd fun, go to my other blog.