In attendance: James, Larry, Tim, Paul, Andrew, Robert and Amy
Avionics Team Field trip to OGI: "Introduction to Extreme Programming (XP)"
We all met at the Oregon Graduate Institute (http://www.ogi.edu) to hear Ward Cunningham (the father of the wikiwiki web - http://www.c2.com) give a lecture on Extreme Programming (XP). We all agreed it was a good lecture, and some of XP even applies to our project.
XP is a programming methodology that emphasizes testing first, testing often, short code iterations, programming in pairs, and is part of a class of methodologies called "agile" methods. For more information, see:
- A good introduction: http://www.extremeprogramming.org/
- Local group: http://www.xpdx.org/
Processing the lecture over beers and fries
We retired to the Cedar Hills McMenamins afterwards to process the lecture. Here's what we thought was particularly relevant to our project, and what we think we should try to implement.
1. Test first, test often
In XP, you write the testing function first. Then you write the code. Then you test the code you just wrote with the testing function. If it works, then you add more to the testing functions and only then do you write more code. This way, you always have working code. I think everyone agrees that if you write the test case first, you also have a better idea of what the code needs to do since you have already formally expressed the major functionality of code via the tests.
In many ways, this can only be done in a software only environment. The closer you get to the hardware, the more expensive or impractical the test is. So we agreed the FC software should implement this kind of testing, and do as much as we can in the little CAN processors although it won't be as much.
Note that this testing is for the code development and not for final code verification. We need to test the hell out the system as usual - for XP, the test code is to make sure the major functionality of your code works. I think the hope is that you cna get rid of most of the small bugs up front using the test cases, and leave all of the nasty weird system bugs for the end. Fun!
2. Small Iterations
XP emphasizes very small code iterations. This means you write the testing function, and then write only enough code to handle the test, and try it. They talked about checking the code in to the RCS every 10 minutes (!) so you can see they're serious about small iterations. Although that's a bit impractical for us, we did agree that taking small steps is good, and that we should encourage this type of programming.
3. Spike Solutions, Coding Simplicity and Refactoring
Many programmers will "hack" the solution to a problem, throw out the code, and then reprogram it in a more intelligent way. The hack is called a "spike solution" in XP and proves that you can solve the problem - although not necessarily in the best way possible. Once you've solved it, you can then throw it out and "refactor" the code - distill it down to only what is necessary, simplify it, etc.
In XP, one does not attempt to "go overboard" with the code - you only write what is necessary and no more. No stubs for future functionality, no thoughts on what next. Because whatever is next usually doesn't look anything like what you imagine it to be, many times this added code just gets in the way.
4. Pair Programming
We all agreed that having someone look over your shoulder while programming is a Good Thing(tm). Although it's hard for us to do as a volunteer group of individuals, we should attempt to do this as much as possible. The second person does everything from catch stupid mistakes to point out other ways of accomplishing a task.
Next Meeting
- Possible workshop Sunday 12/9. Check your email for confimration.
- General Meeting Tuesday 12/11. We'll get some work done afterwards.
See you then!
-- AndrewGreenberg - 06 Dec 2001