Archimedes marketing

On my trip to São Carlos, I read most of Karl Fogel's book: "Producing Open Source Software" which I bought to help me on my masters. I realized Archimedes' greater problems come from my lack of care to the marketing department. I have been failing over and over to gather volunteers as well as keeping my users interested.
Most of this is due to the very low rate of updates at the website as well as the access failure caused by the University's server being down. I am planning to move both the website as well as the svn server to my Dreamhost account. This would allow me to maintain a much more customized website with a few integration tools that I find essential. I will keep the SourceForge website up and running but most of it will be proxied to the website.
The next month will be very busy (you could see that on this post) but I am already working on the website both on the layout as well as the application. I will try to maintain it agile and balanced with Archimedes' development meaning I will try to release partial versions slowly. The first step is to transfer the domain's DNS to my Dreamhost account and set up the basics. I would most surely like to have some feedback on both the layout (with suggestion) as well as the content (once I have something online).

For now, I let you with that screenshot of what I thought about and hope you can provide me some feedback. Thank you!

In-company Dojos

Hello everyone.

Last Friday, I was invited by Kiko to São Carlos to organize a Coding Dojo at his company, Async. As usual, the Coding Dojo practices was a bit hard at the beginning but pretty quickly, the team started realizing how hard it was to think about software solutions collaboratively. The interesting part is that those are free and open source software developer. However, there is very little in their work methods that really gets them to collaborate on very short periods.

They stated that the Coding Dojo is an amazing experience to meet your collegues. Obviously, they work on the same room but they ment that the Dojo helped them understand how their co-workers thought and solved problems. Obviously it also showed how TDD (Test Driven Development) can help find errors and drive their designs even if they were pretty much skeptic about it at the beggining.

I am starting to consider a Coding Dojo as an amazing practical way to demonstrate the benefits from TDD, from quick "releases" and pair programming. It also teaches how to deeply collaborate with other programmers both teaching them new ideas as well as learning from them and follow their ideas. I believe that if it was only the capability to adapt your ideas to someone else's, the Coding Dojo would already be amazingly valuable to most teams. I would, therefore, suggest it as a consulting exercise to new and old teams. Still have to see the future effects it will have to Async's team but I believe communication between them can only improve.

I'll wait and see but will surely apply it to future works. I suggest you try it at your work if you have the opportunity and if you need someone to help you, please contact me. If I cannot go myself, I will try to point someone else.

Coding Rumors or Telephone Coding Game

I "invented" this game yesterday before Sao Paulo's Coding Dojo meeting started. We were going to celebrate one of the attendee's birthday after the meeting and I started this idea being a joke. I suggested we could go have the Dojo at the restaurant.
Someone pointed out that we could not because there would be no way everyone could see what was going on. It then stroke me that this was a full exercise itself.

The idea is to gather at least 8 people around a table (a round one preferably) with one laptop (the token). To start the game, the group must choose a language and environment they are all familiar with (this is very hard, might only work with certain groups of people). After that they have to choose a problem. Make it a very simple problem to start with. Something such as Roman to Numerals or The Block's Problem or any other that everyone in the can quickly see a solution. Once everyone understood the problem, the game starts.
Get a chronometer to define a round time (I suggest 5-7 minutes as we do at the Coding Dojo) and give the laptop to someone. At max 3 people will be able to look at the laptop's screen at the same time: the one coding (the pilot), the one that just coded (the retired) and the one that is about to code (the rookie).
During a round, the pilot has to follow the TDD cycle (test, pass, refactor) explaining the rookie what he is trying to reach. He can ask for help from the retired to better understand the existing code but should not let him touch the keyboard. Once the round is over, the pilot hands the laptop to the rookie and becomes the retired. The rookie becomes pilot and the person next to him becomes rookie. The game should go on until the solution is ready or each participant received the token three times or when a pilot is not able to produce any effective change to the code in his round.

I would suggest a local version control repository (git, mercurial or even svn) to be used at each pilot change so that the group can review the code evolution afterwards and evaluate on what were the key moves in the game that made it success or fail.

I suspect it will be VERY hard to reach a solution on this game but I am pretty sure that playing the game can only be an very rich experience. If the group does manage to reach a solution, I would also say the resulting source code will be very simple to understand and tests will define very well how the methods (or functions) should work.

As I said, I will try at PyCon and I will report the results here when I have them. If you try to play the and have suggestions for it, please post a comment. Have fun Telephone Coders :)

Upcomming events

Archimedes is still stalled since I have been gathering some interesting activities lately.
I'll state chronologically:

• I have been invited to go to São Carlos this Friday (September 12th 2008) to join Kiko (Christian Reis) at Async for a Coding Dojo session in Python with members of his team. Kiko is currently employed by Canonical and is working on LaunchPad for a while. Although I met him at the beginning of the year, we met again at Agile 2008 where we had a better chance to chat which resulted in presenting him the Coding Dojo idea which he liked. Since Danilo is not here in Brazil to help him with it, I am the one that became responsible for that.
• Monday, Tuesdays and Wednesday, I will be one of the four monitors of Bruce Eckel's workshop in São Paulo. Bruce will present his future book's ideas about patterns. Luciano Ramalho invited me and São Paulo's Coding Dojo community for this event which will probably last the full three days and will focus on how to identify, use and understand patterns. Knowning Bruce's work from Thinking in C/C++ and Thinking in Java, it will be a very interesting experience. I will post about it when I get a chance.
• From Thursday to Saturday, I will be in Rio de Janeiro since Kiko invited me to present a Coding Dojo with Async's folks at PyCon Brasil. I haven't booked my flight (or bus ticket) yet but I expect to stay there for the whole conference. We intend to present at least a couple Dojos at Async's booth. I will also try to set up a new kind of Dojo exercise with R (Rodrigo Bernardo Pimentel). The idea is pretty aggressive but aims to pick on a very touchy point in every organization's project. I will explain the game on my next post but just to let you wander, I named it "Telefone sem fio" after the Chinese Whisper game's name in Portuguese thanks to Mariana's suggestion. The name will probably change once I've played it once but for now that should do.
  
• After that I am giving two courses with Mariana and Dairton Bassi over two months about Object Oriented modeling with UML and an introduction to eXtreme Programming. Both courses will be given to University's employees that have over 20 years of programming experience that are migrating to Java and a more dynamical environment.
• October, the 3rd and 4th I will be at Brasilia to present a talk about Squeak and Seaside in the Free Software Festival (Festival de Software Livre-DF). I intend to present how to start a seaside application from scratch and deploy it. I am not sure I will be able to include tests for it but I surely would like to.
• October 11th, I will attend to (and I am organizing) the "Encontro Ágil" (Agile Meeting) that will take place at my college's building at the University of São Paulo. It will be a full day of talks and a few Birds of Feather and discussions. The small logo of participation:
  
  
• OOPSLA 2008 will be held in Nashville, Tenessee this year from October 19th to 23th. I will be there with Mariana. We leave São Paulo the 15th and come back the 25th. A day before my works at the municipal elections.

This is an overall of my activities for the next two months. I am loving all those things to do and travels and conferences to attend to. However, I am pretty sure I am way too overloaded for what I can really handle. Let's see how things go.
That's all for now, I will write about my new coding game in my next post. See you.

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!

Thurday at Agile - No lunch

Thursday morning started just like the other mornings: breakfast in the Grand Ballroom but with most people late. I guess Wednesday evening was quite exhaustive to many people.
I went straight to the Learning & Education stage where I could enjoy an amazing double session (went all the way through morning) of Game Design. This was NOT software game design. It was "hardware" game development. The idea was how to create games that could be used to teach concepts to people. Hubert Smits from Railly introduced shortly the work of Sivasailam Thiagarajan (aka Thiagi at www.thiagi.com).
After a short introduction, Hubert explained that we were going to build a game to teach Sprint (or Iteration, depending on your flavor of agile) planning.

We started by playing a game ourselves. Each os uf wrote down 4 cards with strong opinions he had about iteration planning. Hubert collected all of those and shuffled them redistributing 3 cards to each person. He asked us to sort the cards according to the importance we attributed to the sentence on the card. Meanwhile, he was laying down the rest of the cards on an empty table. Once we were done, he asked us to come to the table, now full of cards, and exchange the cards one by one on our hands with the ones on the table if we considered them more important. When he realised we were all happy with the cards we had, he asked us to trade cards among ourselves following the same idea to increase the value of the cards on our hands (according to our personal opinions). Finally, he ordered us to join with two or three other people and form a group. The group would have all the cards from its members and was to chose three cards that they would hold as theirs. The wrapping up was to have each group present their cards explaning why those cards were important to them.
I found this activity very interesting to align people's expectations about something. I could understand that it was a very good way to have people accepting other people's ideas. Hubert suggested it could also help building a team since the involved people would go from an individual perspective to a group perspective. To me, it looked like a very good ice breaker to get people thinking together.

The next part was the most important one and the goal of the session: to develop our very own game about iteration planning. It was a pretty simple board game. Each player had a character that was in a path leaving from start and aiming to reach the end. The initial rules that Hubert gave us were simple. All players receive about 10 cards at start and those are given back after shuffled when they are over. A player can only go forward if he presents a card that fits the stage in which he is. A player can challenge the presented card if he believes it does not fit that stage. Upon a challenge, all the players in the game should discuss the matter and reach a concensus. If they decide the challenger was right, the challenged player cannot go forward. On the other hand, if the challenged player was right, the challenger goes back one move and the challenged goes forward regularly. The first player to reach the end wins.
Based on those simple rules, we were supposed to define the stages of our game and then write the cards that the players would hold. That was a very interesting activity. It made us think a lot about what were the steps we considered essential in the planning and generated lots of discussion. We then had to gather all the cards we wrote individually and have them classified into the stages we defined. After that, we could change a few rules that we believed would improve the game. Finally, we played our own game to make a few changes with the game experience. We discovered the whole stage stuff was very boring since it took a long time to change stages. The idea that solved it was to have the game being iterative itself. Meaning each move would bring you to another stage and once you were done with the iteration, you would start another until you reach the end.
I loved that experience. It was a great way to have people think about their working system and how to teach it to others. Keeping a coach around as a game driver can be very useful to correct mistakes that the team can make. Finally, playing the game sounded a bit exhaustive but creating it is very revealing. The best part is that such game can be created to teach almost any process or complex non deterministic flow.

During the game session, Danilo, Mariana, Arnaud, Dan and Liz were working on the Block Problem with a Haskell solution. The most innovative idea was to set up a mercurial server (version control) and commit each step so that people could work on their environment and keyboard (Dan had a dvorak keyboard while Arnaud has an azerty one). Once I managed to take them off the, Mariana and me went have lunch with Danilo, Kiko and Bonnie Aumann (which we met at Kiko's presentation on Tuesday) at the CN Tower (CN stands for Canada National). It was a really good lunch with a great view and the chat was very pleasant. Kiko insisting that I was the french one so I should choose the wine and saying that being old (around 35) was way better than being young (around 25).

We came back from lunch about 30 minutes late and I went to my work on the Mezzanine floor. I used the half first slot I had left to relax a bit and review the things I want to ask for reruns. The second slot of sessions in the afternoon was filled with a Panel about open source and agile. The session was organized by Dennis Byrne and had Dirk Riehle, Mary Poppendieck, Naresh Jain and Christian Reis (Kiko). The discussion turned around what are the advantages of open source development that agility disregards or lost. Mary was very sharp as always which made the audience defended itself and attack a few points. I would not be capable of summarizing all we discussed there. The two main points that open source have were setting the user's expectation low and having volunteer work (and therefore committed workers).

After that, we all went to the Banquet where we could enjoy Uncle Bob's talk about Clean Code. Many blogs have already reported what happend but I would like to focus a bit more about his (re-phrased) point: "Craftmanship over Execution". I understand this as a consequence of all the refactoring value we have today. Nobody can sistematically say that refactoring is done. It can always improve. I have to admit I face frequently the question about when should I refactor some piece of code. Should I do it after I've written it and I master it? If I do so, I might be waisting time on something that will never be used (this code won't be extended). On the other hand, if I wait to refactor only when I need to, my code can look really crappy and it might take me some time until I remember how the code was supposed to work. Most of the time, I find myself refactoring things until I just have the feeling that it is enough. I don't know what makes me feel good enough with the code but, at some point, I accept it can be left the way it is even if more refactoring can be done. This sounds obviously as a support to the craftmanship theory since this "intuition" can only come from learning and experience. But shouldn't such motivations be triggered by some regular facts that could be documented? How do we create our craftmanship book? I have no idea but would surely like some tips.

Finally to close the night, Kenji Hiratabe presented himself with 10 other Japanese people by singing the well-know "Dear ecuspi (XP)". For those of you who lost that moment, check it here.
Believe me, around 800 people stood up and sang and danced hearing that. It was really fun!

Well, I am almost over for my reports. I hope I will post Friday by the start of next week. Then I should get back to my regular activities (Archimedes and Squeakasts). Bye bye everyone.

Wednesday - a free night at Agile 2008

Wednesday was the day without receptions. The day started as usual: breakfast at the conference. Donnuts, fruits, cakes but no croissant or pain au chocolat this time. Sessions started at 8:30 as usual and I was doing my volunteer work on the room where I was going to present the Coding Dojo with Danilo and Mari. We were a bit late for the beginning of the stage because Microsoft's reception was a bit too open on the drinks (this is obviously NOT a complaint).
It was on the Learning and Education stage. It started with a nice presentation from Laurie Williams about the work she has been doing with other teachers/researchers regarding pair programming. They made up a nice funny video to stimulate teachers to adopt the pair programming practice in their laboratories explaining the advantages it presents as well as evaluation modes that could be used to assign grades to each student. The video was a bit exagerated in the way it presented the facts which gave it a humorous profile. Although I believe there is more work to be done on that presentation, it is a very nice start. As far as I know, the video is not yet available but should be once they consider it ready. If you want to help, please email her at williams - at - csc.ncsu.edu.
After that, Garry Berteig talked about the Learning Circle. He stated that there are four entry points into a learning circle. Action, Reflection, Learning and Planning are stages through which we pass through when learning something new. He established those four points as quarters of a circle in which the center is guidance. Guidance is what helps keeping someone in that circle efficiently. He then elaborated how to support each activity and how to lead one to another. He got short on time by the end just when he presented how this can and should affect the way agility is taught.
On the third slot of this 1h30 was the presentation of our Coding Dojo in Sao Paulo experience report. Danilo posted some infos about our presentation here. I would like to highlight the map we built on google maps to show where are the dojos around the world.


This is a reproduction of the image but I would really appreciate it if, in a few years from now, this map counted more dojos in north and central America, in Asia and Australia and in the west coast of south America. Europe has a few dojos but I would also expect to find more options since there are so many countries close to each other and ideas should pass around more quickly.

During the second half of the morning, I stayed in the room to fulfill my volunteer work but could not stay focused since I had to take care of another 3 rooms so I used my time to post the Tuesday report. Danilo and Mari went to the OpenJam where they met with Emmanuel Gaillot, Arnaud Bailly and some other people to have a Coding Dojo session. They presented the Block Problem and started to solve it in Ruby. I showed up a couple times but could not help them. They could not finish the problem but liked it so much that Arnaud and Emmanuel worked on it later on (I'll explain more on the post about Thursday). We then had lunch at the conference and attended the Programming with the Stars event. It was quite cool again (I attended on Tuesdays too) with some pretty good demonstration since they now had more time to code (6 minutes).

After the lunch, I went to a session with Esther Derby where she was going to talk about Crossing Cultures. It was going to happen in the French stage (although it was going to be in English) and she had planned a nice game to show how mixing cultures might be hard to endure. Unfortunately, she needed at least 8 people to run the game well enough and we were 7. So she had to cancel it and I was orphan for the rest of the afternoon. Later on that night, we went have dinner with Danilo and the Toughtworks' fellows which was a very pleasant night.

I'll continue on later with more about Agile and after that series, I'll try to get back to my regular activities. Hope you enjoyed it and bye bye.