This is of course pretty controversial stuff, and in all honesty, Arlo only has his own data and the feedback of 6 teams that tried it as supporting evidence that it works. Of the 6 teams, all had productivity boosts. 4 teams continued, 2 stopped. The reasons why they stopped was interesting, though: they liked specializations, and were happy with slightly less productivity.
The final practice Arlo described was team-owned tasks. Avoiding assigning tasks to people is very important to encourage team responsibility, which leads to team accountability, which is a necessary requisite to building strong self-organizing teams.
Another question they had was:
The normal approach is to put the most qualified implementor on a task. Naturally, that should ensure the task got done faster and better, right? Well, just to see how it worked, they once tried the exact opposite: putting the least qualified implementor on a task. Again, what they found was astonishing.
Arlo’s team wanted to be extreme, and they started with one of the XP practices, pair programming. Going extreme meant that they would pair program all the time. No code produced by a single person was allowed to be checked into the repository.
But, pair programming is also a pretty new and relatively undefined practice. There were still a lot of questions open, among them:
How long should each pairing session last?
The most interesting and eye-opening talks at EuroPython 2007 were probably Arlo Belshee’s talks on agile methodologies and his team’s experiments and results in that regard. The following blog posts summarizes what I learned from listening to his talks, doing his XP workshop, discussions with him, and digging up related information on the web (such as a paper and a podcast). I strongly believe this could be the next phase in how we develop software, and I hope I’ll be able to whet your aptetite for change as well 
Some cool REST links I’ve come across lately:
A while ago I discovered that by setting an HTML INPUT tag’s type attribute to search, Safari on OS X would show the OS X search widget instead of the standard boring HTML input field. Andrew Escobar has a good introduction and an example screenshot:
This search widget is extremely user-friendly and space-efficient; there is no need for a “Go” or “Search” button anymore.
It also downgrades gracefully to a normal input field for other browsers, but this is unfortunately not enough:
Taken together it means you have to add explanatory text and a “Search” submit button after it for people to understand how to use it, destroying the user-friendliness and space efficiency and offered by the Safari widget.
I’ve noticed that more and more sites were using the Safari search widget without any “Search” submit button, so I figured they must have found a way to make it cross-platform. I spent some time on facebook.com today and noticed they had the Safari search widget… and… sure enough, for Firefox and IE a nice JavaScript version!
I decided to do some reverse engineering…
I caught this very interesting announcement on the Django Developer group:
I like Django, and my unique experience having grown up in a fishing village should make the ideal candidate! If it wasn’t for the fact that I hate cod…
I wasn’t expecting to see Google go so far as to branch into seafood. No industry is safe anymore…
In liu of a real fulltext search engine for Django, you may just want to use the same simple
search engine that Django’s admin uses. Unfortunately it’s not readily reusable, so you’ll have
to pull it out of the ChangeList.getqueryset
in django.contrib.admin.views.main.