Friday - Last day at Agile

Friday morning was a bit emptier. A few people were leaving or had already left Toronto. Breakfast was calmer and everyone was interested in the sessions that were elected to be rerun after lunch. About 40 sessions were going to be rerun that were chosen by the attendees by voting on one session per day.
On the first slot in the morning, I attended a talk by Arnaud Bailly with Emmanuel Gaillot and Mariana. Arnaud presented us a small game about Haskell intended to teach young students how to solve problems in Haskell. The game is formed by tiles of lambdas, basic operations, color tiles to match variables, pi to describe the pattern matching and a few numbers. The first exercice we did was to write the factorial of a number. The recursive version came out pretty quickly and when we tried to expand it to get the solution, we noticed the huge amount of tiles needed. It was a great way to realize the amount of memory needed when stacking everything. We worked our way through the tail recursion version in which we could realize that the stack was never greater than 2. I found it a very nice way to show students the consequences of those details.

After the coffee break, everyone went to the Grand Ballroom to the last Keynote of the conference. This time, Alan Cooper, creator of Visual Studio (later sold to Microsoft) and author of several Human-Computer Iteraction books, presented his point of view about Agile and the way software is developed. It was a quite controversial talk. Alan presented his view point regarding the software development process. According to his speach, there four main stages in software development. The first one, "The Big Idea", is completly out of scope to any software development method. It is a creative process that is accomplished by the business experts and developpers should not be involved.
After that stage comes the Design stage followed by the Engineering stage and ending by the Construction stage. He states that Design and Engineering are stages based on iteration and increment, therefore, those are agile stages. And this is where Agile gets it right. However, construction is NOT an iterative stage. Purely incremental. Simplifying a lot, he says that all software should be built once, using agile methods, to be thrown away (since Brooks said, in The Mythical Man-Month, "Plan to throw one away, you will anyway"). After that first sketch, the software should be built from scratch without agile methods. His argument is that the first time, you will discover several new things while you walk ahead. Those things will impact on your software making it harder to understand and more complex. The second time, you already know those problems and can handle them previously working without surprises.
What I don't understand in this way of thinking is why rebuilding the software the first time? The only reason I can find to do that is because you want to change things in it. But if you do, you might encounter more problems and end up having to throw your second attempt away too! And you can go on like that over and over and over. The other question is why not refactor your first version to make it less complex and hard to understand? Maybe it is more expensive to refactor the whole software than starting it from scratch. But if this is true, then you obviously will have new decisions to make when you restart and you may just as well end up with the same problem at the end.
Anyway, the rest of the talk was about how interaction designer can improve the overall quality of the first software development. To this part, I have little to talk about. Alan's presentation can be found in his company's site. I totally agree that interaction designers are very usefull but I oppose to the idea that developers are not supposed to understand a little about their work and be able to perform a few of their tasks. I agree that in all field there should be experts that can help generalists. But I pretty much like the generalists that are able to do the whole thing decently even if it is not excelent. There is a nice article Danilo wrote about the Generalist/Specialist paradox. I believe nobody can be a specialist in all fields becoming therefore a generalist specialist. But I can understand having lots of generalists that have one specific area of expertise. To have a great agile team, all you need is that your generalists have different expertises and everyone knows about it.

Back to Agile. After the keynote, lunch was served in the corridors and I got ready to attend Kenji Hiratabe's double session. The first one was about the lessons he learned from the chief engineer at Toyota's development and the second one was a video about the migration of a traditional industrial chain to a "Yaigi" system. Those were a couple of amazing talks. I won't be able to summarize everything decently. I'll just say we have a LOT to learn from oriental cultures. Working in such environments where respect is a key is an experience I would like to have in my life.

That was the end of Agile 2008's reports. It took me three weeks to post my summaries of the five days I spent in the conference but it was worth it. My best advice is to search on the web for more reports and maybe even slides from the event. Also, stay tunned for next year's Agile to be realized in Chicago. If you want to attend Agile but don't think you can afford it, try getting in as a volunteer. You don't need to be a student to apply for it and it saves you the inscription fee which is considerable. In the next days, I will be returning to my usual posting subjects. Archimedes is the next one and I will try to go back to short posts. Hope you liked it. bye!