Brought to you by the combined power of phlegm and NetNewsWire, a pile of links relating to software development:

• Clarifying the purpose of iteration planning. I'm booked onto the Mike Cohn course in London in a few weeks time. I'm so excited. And I just can't hide it.
• The perception of agile seems to be on a knife-edge between recession-busting common sense and meaningless management drivel right now.
• Joel Spolsky on servant leadership: "I'd love to imagine that I'm the most valuable person in the company, that my time is so precious that I have to optimize every minute. But it's not true. At this point, I'm probably the worst developer in the office."
• Logging styles: "Resist the tendency to log everything"
• Nice piece on growing an agile organisation: "These ideas are easier to give lip service to than to actually implement. So if it doesn't work right away, don't give up."
• David Wood ventures down a similar path: "Being big can have its advantages as well as its disadvantages, so long as individual parts of the company have sufficient autonomy"
• What have you tried? "The problem is that this person’s problem-solving technique is to ask for the solution... but to just ask for the code, fully formed and ready to go. This is not problem solving, and software engineering is entirely about problem solving."
• Static methods: the death of testability
• Lean and Kanban for game developers;
• Why pairing sucks in '08, a nice writeup of a session at XP Day exploring why developers choose not to pair.
• Writing testable code: "To keep our code at Google in the best possible shape we provided our software engineers with these constant reminders. Now, we are happy to share them with the world."
• Can't work out whether I like this article, since it seems to simultaneously promote every point of view: "don't optimise, hardware is cheaper than people", "fast hardware won't save you from bad code", "you can always improve performance", "optimising is hard", etc etc. Hardware-is-cheaper-than-people is often a lazy way of justifying crap IMHO, and ignores some of the complexities of scaling up beyond a single node.