tag:blogger.com,1999:blog-15975717118239664542024-03-13T09:09:28.819-03:00CodeAcheThe headache one can have with codesHugo Corbuccihttp://www.blogger.com/profile/08306316717477317361noreply@blogger.comBlogger89125tag:blogger.com,1999:blog-1597571711823966454.post-81909482436718364132010-01-04T10:13:00.003-02:002010-06-16T09:45:59.588-03:00Agile 2009 - Day 4 - 27th August - Climbing the Dreyfus ladderOn the last of Agile 2009, I started with the last half of Jim Highsmith's talk: <a href="http://agile2009.agilealliance.org/node/409">Agile Project Management—Innovation in Action</a>. I have little to say about it but better that can nothing.<br />He proposed an interesting change on the view of the production "iron triangle". The traditional one having scope, resources and schedule has its constraints. He suggests that in an agile environment those constraints are, in fact, all parts of one corner alone: "Constraints". The other corners being value and quality. I don't have many notes on this talk so I can't add much more.<br /><br />On the second slot, I went to <a href="http://www.thekua.com/">Patrick Kua</a>'s <strong style="font-weight: normal;"><a href="http://www.thekua.com/atwork/presentations-and-papers/xp2009/">Climbing the Dreyfus Ladder of Agile Practices</a></strong>. It was a great experience. The main idea of the workshop is to help coaches set up their expectations regarding the use of practice within their teams. Patrick started with a small presentation about the behavioral model such as <a href="http://alistair.cockburn.us/Shu+Ha+Ri">Shu Ha Ri</a> and the <a href="http://en.wikipedia.org/wiki/Dreyfus_model_of_skill_acquisition">Dreyfus model skill of acquisition</a>. His slides are available <a href="http://www.thekua.com/atwork/wp-content/uploads/2009/05/climbingthedreyfusladderofagilepractices.pdf">here</a>.<br /><br />The mechanics were pretty simple.<br />Choose a principle or practice you would like to map. I got into the group talking about Story Walls/Big Visible Charts.<br />Ask people to write down post-its with desired actions or atitudes they expect to happen for this practice.<br />Once they are done, have them identify on which level of your behavioral model each of the actions they wrote down should fit. Would you expect a beginner to perform that action? Or is that something more common to someone proficient? Some discussion will lead to a mapping of the actions to each level.<br />With this result, your coaches are now aligned regarding what they might expect from their teams and how they can identify those who managed to climb the ladder and, mostly, how to help people reach a higher level by slowly going up one step at each time.<br /><br />The results of our workshop are available on <a href="http://www.thekua.com/atwork/presentations-and-papers/agile-2009/">Patrick's website</a> and I strongly suggest this activity to help your teams set a common expectation and improve consistently the members of your team.Hugo Corbuccihttp://www.blogger.com/profile/08306316717477317361noreply@blogger.com1tag:blogger.com,1999:blog-1597571711823966454.post-36423422018789474802009-11-22T11:59:00.003-02:002009-11-22T12:35:15.734-02:00Agile 2009 - Day 3 - 26th August - Kake Coding DojoOn Wednesday evening, after the talks were over, I organized a <a href="http://codeache.blogspot.com/2008/10/coding-rumors-or-uberdojo.html">Kake Coding Dojo</a> at the open jam area. We had 3 computers (my own running OS X, Thiago Colucci's with Ubuntu Linux and Pedro Leal's one with OS X) and about 10 people participating.<br />We chose <a href="http://codingdojo.org/cgi-bin/wiki.pl?KataBowling">Kata Bowling</a> as our problem.<br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://farm4.static.flickr.com/3422/3861612469_5d03b292f7_b.jpg"><img style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer; width: 768px; height: 1024px;" src="http://farm4.static.flickr.com/3422/3861612469_5d03b292f7_b.jpg" alt="" border="0"></a>We built up the nice sheet you can see above (thanks <a href="http://www.dtsato.com/blog">Danilo Sato</a> for the picture) with our explanation of the problem as well as the mechanics. This way, we intend to get people to join us on the fly while the dojo was already running. And it worked! We had about 3 or 4 people that came by, joined for two rounds and then left. A few people kept around just chatting about what was going on and wondering how to things were going. Thanks Pedro Leal for the picture below.<br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://lh3.ggpht.com/_9QZIXmDGHKk/SqAaIs30KeI/AAAAAAAAAMY/lFXDyLdFwWM/s640/CIMG1594.JPG"><img style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer; width: 640px; height: 480px;" src="http://lh3.ggpht.com/_9QZIXmDGHKk/SqAaIs30KeI/AAAAAAAAAMY/lFXDyLdFwWM/s640/CIMG1594.JPG" alt="" border="0"></a>The same problem was being solved in Ruby, Haskell and Java on each computer and it worked about fairly well in all of them. We kept 7 minutes round as usual and just had some problems with missing experts on Haskell (just two people very familiar with the language and 2 more with some experience) which drove us to ask out for help to other Agile attendees.<br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://lh4.ggpht.com/_9QZIXmDGHKk/SqAaVEaPENI/AAAAAAAAAMs/8aoo4fNtI0k/s640/CIMG1598.JPG"><img style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer; width: 640px; height: 480px;" src="http://lh4.ggpht.com/_9QZIXmDGHKk/SqAaVEaPENI/AAAAAAAAAMs/8aoo4fNtI0k/s640/CIMG1598.JPG" alt="" border="0"></a>Finally, we ran our retrospective which the result you can check on the picture above (or <a href="http://lh4.ggpht.com/_9QZIXmDGHKk/SqAaVEaPENI/AAAAAAAAAMs/8aoo4fNtI0k/CIMG1598.JPG">this link for the higher resolution one</a>).<br /><br />Our main problems were about the noise around (downside of being in an open area) and our lack of detached keyboards (which could have jumped from hand to hand more easily). We learned (the hard way) that changing a pair in the middle of a big refactoring is really hard. It is very difficult to explain what is happening to the newcomer when the code is not working.<br /><br />People also liked trying Ruby and Haskell but mostly the experience of pair programming with different people from different backgrounds. There was a small issue regarding the stress situation that the format puts participants on. 7 minutes is a short time and having the pressure to explain the code to the newcomer and adding your own contribution in that time (not being able to fail on any or else the whole code might get lost) is not an easy and comfortable situation. From this view point, the format breaks the safety aspect so important in a Coding Dojo. On the other hand it also leads to a more exciting experience and gets you to practice a different set of skills.<br /><br />On the overall it was an amazing experience and I would like to thank everyone for joining us. After so much fun, we obviously went out for some dinner at an <a href="http://bostonblackies.com/">amazing burger place</a> in Chicago.<br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://lh6.ggpht.com/_9QZIXmDGHKk/SqAaXVHIuDI/AAAAAAAAAM0/CjgF1nc3ATo/s640/CIMG1600.JPG"><img style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer; width: 640px; height: 480px;" src="http://lh6.ggpht.com/_9QZIXmDGHKk/SqAaXVHIuDI/AAAAAAAAAM0/CjgF1nc3ATo/s640/CIMG1600.JPG" alt="" border="0"></a><br />You can checkout the generated code of the three solutions at <a href="http://github.com/dojosp/participant-s-projects/tree/master/05-KakeAgile2009/">Coding Dojo São Paulo's github account</a>. There are also more pictures from <a href="http://www.flickr.com/photos/dtsato/sets/72157622159130152/">Danilo at his Flickr account</a> and some more from <a href="http://picasaweb.google.com/pedrombl/CodingDojoKakeAgile2009Chicago">Pedro at his Picasa account</a>.<br />Hugo Corbuccihttp://www.blogger.com/profile/08306316717477317361noreply@blogger.com4tag:blogger.com,1999:blog-1597571711823966454.post-54402746150053632642009-11-22T11:09:00.003-02:002009-11-22T11:56:15.960-02:00Agile 2009 - Day 3 - 26th August - PlaceboThings have gone smoothly (and busy) since last post so I am back to finish my report about Agile 2009. On Wednesday, during the morning I was assigned to Robert Biddle's talk about "<a href="http://agile2009.agilealliance.org/node/3098">Activity Theory for Manifesting Agile</a>" which was a very good and a bit too complicated for me. Since I was working couldn't get any notes so I'll skip it just like Johanna Hunt and Rachel Davies' "<a href="http://agile2009.agilealliance.org/node/1989">Telling Your Stories: Why Stories are important for your team</a>" workshop. The workshop was pretty fun and I managed to help a little. A brief description would say that it consisted in getting people together to invent stories they've been through and listening to other people repeating them. Interesting results but I can't detail them by lack of notes.<br /><br />So for Wednesday afternoon I got a little more time. Not knowing what to attend to, I wandered around during the first slot and ended up (very luckily) at Linda Rising's "<a href="http://agile2009.agilealliance.org/node/408">Agile: placebo or real solution?</a>" session. Best thing that could happen to me was to get into that one. Amazing talk.<br /><br />Linda started telling us about what is the <a href="http://en.wikipedia.org/wiki/Placebo">placebo effect</a>. This effect is now know to exist for a fact and its outcomes are pretty impressive: about 30% of sick people get better no matter what is the medicine that is given to them.<br />She explained that quite a few experiments have been done regarding this effect. Those experiment show that if you get three people with the same diagnosed disease and you give them all a pill with placebo (which has absolutely no medical effect) without them know it is placebo but really believing that those pills will heal them, one of them will, indeed get better.<br />One important point is that the patients have to <span style="font-weight: bold;">know</span> that they are being treated. The test has absolutely no effect if the medicine is given without the patient's knowledge (hidden in the food or water or applied during sleep). The consciousness of being taken care off is of great importance for the effect to take place.<br />There are many more experiments that show off that if there is anything that points to a fake, no results are shown. If the patients are not confident that the medicine will help them (if the doctor shows uncertainty, if they've heard from friends that it doesn't work, etc.), the effect also does not present itself.<br />From those experiments, we can conclude that since belief and awareness of treatment are essentials, it is our own body and mind that makes it so that we get better.<br /><br />Having introduced us for this clinical view of the placebo effect, Linda talked about experiments that were run in order to identify why would some patients (not always to same) respond to placebo and others wouldn't. From some brain analysis, it looks like there are two groups of people. People which she called "sheeps" that are more influenced by their unconscious and people which stick much more with their conscious called "goats".<br />This doesn't mean that you either a sheep or a goat. People can behave like sheep on certain situations and like goat on others. It so happens that the brain activity of people being treated by the placebo effect is very similar to the activities recorded on sheep behavior.<br />So it is people's unconscious that is capable of healing a disease by itself.<br /><br />And what is the relation of such medical results with agile software development? Well, Linda asks us whether all we've been talking about is just placebo and people were just looking for a medicine to improve their situation or is it that there is really an improvement by applying agile methods?<br /><br />The answer she provides is a simple one: who cares? As long as it works, let's keep doing it! She gave this end a very scary religious connotation as she brought some people up-front and started talking like a priest with "Oh yeah brother! Amem!" and stuff like that. It was a fun joke but a bit scary if you saw people joining her (they were also having fun).<br /><br />Anyway, the whole talk was a very interesting one. Sometimes just having someone with authority (a consultant) come in and use whatever claiming it will solve the problems can solve them even if is nothing special. Better think about it when you are facing a problem with a group.Hugo Corbuccihttp://www.blogger.com/profile/08306316717477317361noreply@blogger.com3tag:blogger.com,1999:blog-1597571711823966454.post-58357971867489501432009-10-12T11:03:00.006-03:002009-10-12T15:29:25.224-03:00Encontro Ágil 2009 - Lean Lego GameSlightly interrupting the Agile 2009 sequence (I'll come back to it later). I presented the Lean Lego Game at Encontro Ágil 2009 on Saturday (10/10/2009) with Mariana.<br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://farm4.static.flickr.com/3521/3999188658_e3c31f31c9_b.jpg"><img style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer; width: 1024px; height: 683px;" src="http://farm4.static.flickr.com/3521/3999188658_e3c31f31c9_b.jpg" alt="" border="0" /></a><br />Our slides (in Portuguese) are <a href="http://sites.google.com/site/hugocorbucci/leanlegogame-hugomari.pdf">here</a>. You can check a few pictures of the event (including our workshop) from <a href="http://agileandart.blogspot.com/">Daniel Cukier</a> from <a href="http://www.flickr.com/groups/1259797@N23/pool/">his Flickr account</a>. The session was a success. We had the room filled and people really looked like they enjoyed it.<br /><br />Our results were pretty good. For the pull system hands on, our production line only managed to deliver one house with a total of 300 bricks on stock.<br />On the push system hands on, we got much better and managed to deliver 4 houses and the stock was around 250 bricks.<br />And during the Yatai session, we delivered 8 perfect houses and 1 with a slight defect and had all bricks on tables (about 350 bricks). One nice thing that happened was that attendees actually noticed it and complained about it which lead me straight to Kaizen in a great fluent transition.<br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://farm3.static.flickr.com/2645/3999188368_b0766c1c67_b.jpg"><img style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer; width: 1024px; height: 683px;" src="http://farm3.static.flickr.com/2645/3999188368_b0766c1c67_b.jpg" alt="" border="0" /></a><br />As planned, we finished in around 1h30 which left us with some 20 minutes for questions. Since attendees were a bit shy, it ended up being a story telling session where I shared the story Kenji Hiranabe showed at Agile 2008 about the transition of one of Sanyo's cell phone factories to Lean principles. Too bad the video is not public.<br />We also mentioned the story about a tooth paste factory that hired engineers to build a huge expensive machine that would separate empty boxes from filled ones. Since it would take some time to build the machine, the manager had one of the employees remove the empty boxes from the line while the machine wasn't ready. After a month, he came back to the factory and was surprised to find a pile of empty boxes on the ground and the employee he had assigned to select the boxes doing something else. Near the line was a fan blowing the empty boxes from the production line. When the manager asked why it was there, the employee explained that selecting the boxes manually was too boring and that he felt he would be more useful somewhere else. So he put the fan there and came by at the end of each day to collect the empty boxes and add them back to the stock therefore accomplishing the task that the huge expensive machine engineers were building.<br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://farm3.static.flickr.com/2640/3998430347_3b281f6412_b.jpg"><img style="margin: 0pt 0pt 10px 10px; float: right; cursor: pointer; width: 1024px; height: 683px;" src="http://farm3.static.flickr.com/2640/3998430347_3b281f6412_b.jpg" alt="" border="0" /></a><br /><br />That story is a great example of why Gemba is so important in Lean. People that actually do the work are usually more suited to find simple solutions to problems they have.<br />I hope to receive more feedback from those who attended and plan to present this workshop more often. Any questions or critics are very welcome.Hugo Corbuccihttp://www.blogger.com/profile/08306316717477317361noreply@blogger.com1tag:blogger.com,1999:blog-1597571711823966454.post-60888011936385422182009-10-02T09:09:00.007-03:002009-10-02T13:17:30.945-03:00Agile 2009 - Day 2 - 25th August - Lean Lego GameAfter lunch on Tuesdays I was assigned as a volunteer. On the first slot I took care of "Speed Up Your Testing With Acceptance Criteria Conversations". It wasn't really my favorite session to attend to but I needed some time to rest my mind so I took profit of being near the wifi area (believe me, there was only 1 free wifi spot in the conf) to check my emails and catch up with the world a little.<br /><br />On the second slot, I joined <a href="http://www.dtsato.com/">Danilo Sato</a> and <a href="http://blog.franktrindade.com/">Frank Trindade</a> in the Lean Lego Game session they ran.<br /><br /><span style="font-weight: bold;font-size:130%;" >The Lean Lego Game - Danilo Sato & Francisco Trindade</span><br /><br />The session was a workshop and, by the way it was built, it couldn't handle more than 30 people participating actively. Since I was on duty I couldn't join the teams but had the pleasure to help. The session started up talking a bit about Lean, velocity and cost but mostly explaining that lots of people in the software industry now have heard of Lean but few of them really understand the context in which Lean was born. I'll skip the talk part (slides are available at <a href="http://www.slideshare.net/dtsato/lean-lego-game">here</a>) and go the game itself since it was the most interesting part to me and it is the one that brings back to that first Lean context.<br /><br />The participants were divided in four groups of 7 to 8 people each. Each group was in a table and had another table with a few Lego pieces nearby. The idea is that those four groups simulated a house factory that could do houses of four different colors. There were 3 rounds was constituted of 4 sprints of 30 seconds each. Each round followed a slightly different production system.<br /><br />The first round simulated a production line. The group closer to the talkers were the assembly workers and their responsibility was to assembly a house. The next group was the selection group responsible for collecting the right amount of each part to build a house from a pile of parts from a certain color. The next group was the one responsible for the coloring separation. Their job was to get pieces and separate them into four piles, each with one color. Finally, the farther away group was responsible for "buying" resources from the big Lego bag and providing them (no more than a certain a amount of each kind) to the other group. Each person of the group should have a task and could not do anything other than that task. At the end of each sprint, <a href="http://www.thekua.com/atwork/">Patrick Kua</a> (the house factory customer) selected two colors (randomly from a card deck) for the houses he wanted to buy to simulate a push system where things were done BEFORE the clients manifested a wish for them (like North American car factories used to do).<br /><br />In that scenario, each group knew what do to from start and they followed the colors chosen by the client for that sprint. At the end of each sprint, the talkers collected the results of each group. They counted how many houses were delivered, how many resources were consumed on each stage and the total. This way, the first sprint didn't manage to deliver any houses. Colors were sorted by the client and in the second sprint, the team delivered two houses but one was not from the colors the customer wanted. Another two colors were sorted and one matched the extra house in stock. On the third sprint, the team delivered another two houses but one of them didn't match the requested ones. The last sprint delivered two other matched house. The customer picked another two colors and couldn't get a match so the team ended up delivering 5 houses.<br /><br />The session then talked a bit about could have gone wrong. And the team felt many of them were not having work to do or were doing the wrong work because they didn't know what they should be doing.<br /><br />So the second round changed the system to pull system. Meaning the teams were supposed to work exactly in the same way internally but the client would pick the card at the start of each sprint and the supplier teams would provide supplies of the colors selected by the client. Results were much more impressive this time and the team managed to deliver one house successfully on the first sprint, two houses on the second and third sprint and three houses on the last sprint. This way they ended up with 8 houses sold. However they still consumed more "money" than the houses "paid".<br /><br />This brought up the problems related to keeping a stock and still having people not aware of the whole process. The presenters then introduced the idea of Yatai. So the last round followed a Yatai where each person was responsible for building one house by themselves just picking from the piles available near their tables. Instead of having fours sprints of 30 seconds, the team was given one big sprint of 120 seconds. It ended up that the team managed to deliver 16 houses and the stock was severely reduced.<br /><br />Although I couldn't be part of a team, I really had a lot of fun. People were running around, trying desperately to do their best and getting frustrated over the systems they were forced in. I think Danilo and Frank really managed to bring up one of the key issues brought up by Lean ideas and had a great timing to swap between presentation and activities.<br />I loved the workshop so much that I will be presenting an instance of it at <a href="http://encontroagil.com.br">Encontro Ágil 2009</a> on the 10th of October (next week) in São Paulo. If you want to learn a bit more about Lean and personally feel the industry issues that modeled Lean, join us and help us improve this workshop even more.Hugo Corbuccihttp://www.blogger.com/profile/08306316717477317361noreply@blogger.com0tag:blogger.com,1999:blog-1597571711823966454.post-78522582055299930202009-09-23T09:02:00.006-03:002009-09-23T10:18:31.332-03:00Agile 2009 - Day 2 - 25th August - Top 10 tips to Agile CoachesAfter Alistair's Keynote, I went to Rachel Davies & Liz Sedley's "Top ten tips to Agile Coaches".<br /><br /><span style="font-weight: bold;font-size:130%;" >Top ten tips to Agile Coaches - Rachel Davies & Liz Sedley</span><br /><br />The session was mainly based on a summary from what Rachel and Liz learned through their experience and while writing <a href="http://www.pragprog.com/titles/sdcoach/agile-coaching">their book</a>. I will just write down the tips with my small notes and let you think about them.<br /><br /><span style="font-weight: bold;">10. Get Introduced</span><br />Who are you? What do you do? What is your goal?<br />Explain your point of view to the team you will (or are) coaching and let them understand you are not there to be their boss.<br /><br /><span style="font-weight: bold;">9. Agile is <span style="font-style: italic;">NOT</span> a religion</span><br />Spend time and effort to listen and understand the team and their environment. It might very well happen that agility does not fit their situation. Be sensitive to their context.<br /><br /><span style="font-weight: bold;">8. Show respect</span><br />Always trust (deeply in your heart, not just for show) that people did their best since the beginning and try to understand why they got in the situation they are in.<br />Discover the differences between people and use NAMES ("the BA said that the DB guy couldn't do it" versus "Jenny told me that Josh was having troubles to implement it").<br />Ask what they think about the issues and was suggestions they have and LISTEN to their answer. Pay attention and try to understand. Work with them over those suggestions.<br /><br /><span style="font-weight: bold;">7. Step back to see the big picture</span><br />Don't try to fix people. Try to fix the pressures and obligations those people suffer from so that they can do their job decently.<br /><br /><span style="font-weight: bold;">6. Ask questions to spark ideas</span><br />Questions make people explain ideas and understand them. It also makes them create arguments and counter-arguments for their ideas. If you can make their ideas work, it will help the team adopt the movement and carry on.<br />But be careful: ask questions to other people's ideas, not your own. Do not try to force your ideas through those questions.<br /><br /><span style="font-weight: bold;">5. Take time out to reflect</span><br />Don't let pressure force your answers. Your calm attitude will relax the team and make them feel more confident. Ask help to other agile coaches/people if you can't think of a good behavior. You don't have to know it all.<br /><br /><span style="font-weight: bold;">4. Introduce the Elephant</span><br />Show off the problem that everyone know exists but is silent about it. But don't put it as a pressure. Give the team a chance to suggest solutions, ideas, root causes, etc.<br /><br /><span style="font-weight: bold;">3. Make changes as an experiment</span><br />Go slowly. Try some idea and be ready to remove it if it doesn't work. Don't stick to something that won't work just because you think the team should make it work. Try something else and try it again later, in another context. Give the team chances to suggest those changes and experiment with their ideas.<br /><br /><span style="font-weight: bold;">2. Go with the energy of the team</span><br />Solve the problem the team wants to solve. Eventually they will address the problems you consider important.<br /><br /><span style="font-weight: bold;">1. Have courage in your convictions</span><br />Don't doubt your capacities, the problem is not easy and you can't let people see you doubt yourself. It will discourage them and make them lose confidence in you. Believe you can make a difference or you really won't.<br /><br /><br />After the talk, they asked for each table of participants to add their own tips. A few of them were really good but, unfortunately, I couldn't write them down. Those are obviously good ideas and NOT religions either. Any problem can have its context in which any of those tips can fail. But in general, thinking about them can only help you. Do you have any tip you feel should enter that list? Please post it as a comment. I've attached <a href="http://sites.google.com/site/hugocorbucci/A09-TopTenTipsForAgileCoaches.pdf">their slides</a> although they don't add so much.Hugo Corbuccihttp://www.blogger.com/profile/08306316717477317361noreply@blogger.com0tag:blogger.com,1999:blog-1597571711823966454.post-76324115210204917092009-09-12T11:21:00.005-03:002009-09-17T08:11:31.473-03:00Agile 2009 - Day 2 - 25th August - Alistair's KeynoteTuesday at Agile 2009 started well. The conference provided a very good breakfast with chocolate croissant (I love those), coffee, tea, fruits, juices and different kinds of breads.<br /><br />From there, everyone went to the Grand Ballroom to watch Alistair Cockburn's Keynote. I won't need to write a full description of Alistair's talk because <a href="http://www.infoq.com/presentations/cockburn-bury-not-praise-agile">InfoQ just published the full video of it</a>. So it will be a bit closer to my impressions.<br /><br />First thing I need to mention is that once Ahmed Sidky (Agile 2009 Program Chair) introduced Alistair, we had an amazing performance of Wind's Song Flutes playing the one Scottish music used in all movies and Alistair was following silently behind. Very impressive entrance. Alistair then explained why wind's song flutes players always walk when playing: "They are running away from the sound".<br /><br />Past the fun, came the sadness. Alistair started his talk reciting an adapted version of the funeral oration from Shakespeare's Julius Cesar to Agile Software Development. A very impressive performance. It was the introduction to say not that Agile was dead but that it was melted. He compared Agile to an iceberg in the ocean (software development) and said that before, Agile was something that people noticed because it was outstanding from the rest. Nowadays, the iceberg has melted. It is not gone. But it is now part of the ocean. It is now something that is accepted by most people.<br /><br />He then moved on to his viewing of software development you might know if you read any of his Crystal books or articles or if you attended any session with him.<br />He defines Developing Software as<br />People<br />Making Ideas Concrete<br />in an Economic Context<br /><br />He then showed this image that I particularly like:<br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgiB1ZMfxsYKlWttBtEL73aAkpg5G1S95cPy0uaCDktvMQ4YOmCmvT2sn9Ld5eWlBojSY_OmfrFTW8tY2Mf3I-xk2_oifEQlGG0heBHVqsrfp-gCphdmiSWivtibDwBGHHFW5qO3Omh4PPx/s1600-h/GamesSeparation.png"><img style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer; width: 400px; height: 263px;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgiB1ZMfxsYKlWttBtEL73aAkpg5G1S95cPy0uaCDktvMQ4YOmCmvT2sn9Ld5eWlBojSY_OmfrFTW8tY2Mf3I-xk2_oifEQlGG0heBHVqsrfp-gCphdmiSWivtibDwBGHHFW5qO3Omh4PPx/s400/GamesSeparation.png" alt="" id="BLOGGER_PHOTO_ID_5380591433000715490" border="0"></a>He explains that Software Development can be considered a finite, goal-directed and cooperative game while building IT Systems is open-ended. This means that when you are developing software you should work in a team to reach a goal and you are done when you make the software achieve that goal. On the other hand, when you think about the whole system, you want to work cooperatively in an open ended game. Meaning you are always in a dilemma between delivering the software and setting up for the next software (or game).<br />He says also that this game is consisted of 3 possible moves: Invent, Decide, Communicate. With those moves you have to deliver the software and be slightly prepared for the next game.<br /><br />He then went on to more traditional arguments he uses for Crystal. Team size and criticality of the project are key to decide what practices you should apply. He also mentioned the quality of communication between people and the fact that most means are much more effective than paper to communicate so people should really think about different forms of documentation.<br /><br />He also talked a little about the Craft focus that is being given to software development lately. He pointed that thinking of any activity as a craft helps you identify the skills required to perform it and the medium available to achieve the goal. Moved a little to the User Experience entrance in the process of software development and how things changed or should change to be more effective in overall.<br /><br />It was a very good talk. A bit repetitive for those that already attended any session with Alistair but still very a great talk. I definitively recommend you see the whole video from InfoQ and feel free to post comments to start a discussion on any of those subjects.<br /><br />Next post will present Rachel Davies and Liz Sedley's "Top ten tips to Agile Coaches".Hugo Corbuccihttp://www.blogger.com/profile/08306316717477317361noreply@blogger.com0tag:blogger.com,1999:blog-1597571711823966454.post-44322047296095259372009-09-10T22:27:00.006-03:002009-09-14T09:59:43.988-03:00Agile 2009 - Day 1 - 24th August - Software QualityOn the second slot of monday afternoon, I attended Jim Highsmith's "Zen and the Art of Software Quality". I missed the first 10 minutes but I don't think it was a big deal.<br /><br /><font size="4"><font style="font-weight: bold;">Zen and the Art of Software Quality - Jim Highsmith</font></font><br /><br />When I arrived, Jim was talking about why we should not use the Standish Group Measures to evaluate software development success. The main reason he points is that the outcomes measured are outdated. They focus on projects that are on plan, on schedule and on features.<br />Meaning that a project that is delayed of a year but has a satisfied customer is a failed project.<br />A project that achieves an unexpected goal is a failure.<br />A project that delivers less feature in less time and stops is a failure.<br />Those are wrong concepts. Canceling a project soon enough is NOT a failure. It is a great success from an agile perspective. It means the client didn't waste his money for several months (or years) until he discovered he couldn't afford (or do) what he wanted to.<br /><br />One of Jim's sentence that I liked is:<br />"Target high and miss<br /> might be better than<br /> target low and hit!"<br />What good is it to estimate every story as an epic story and manage to do it in 6 iterations while you could break the story in smaller ones and deliver 80% of the value in 1 iteration?<br /><br />His suggestion from this scenario is that we shouldn't think about the old Cost-Scope-Schedule triangle as our variables in software development. That waterfall iron triangle should be replaced by an Agile Iron Triangle constituted of Value-Quality-Constraint where Constraint would be Cost-Scope-Schedule.<br />His idea is that those are constraints to software development. Variables related that fit in a greater picture. Our questioning should now be something like "how much value can we deliver given a certain level of quality and our constraints".<br /><br />Jim explained then that there are "two kinds of Quality". An iextrinsic quality that is related to the quality imbued from value a given software has for a customer and an intrinsic quality. The intrinsic quality is closer to what we consider quality nowadays. It is the way the software is done. It is its bugless property, its simplicity, etc.<br />Separating those qualities help us understand something we already know. It is useless to produce the perfect software that solves nobody's problem.<br /><br />Jim then defends what I understand as "fail fast". He argued that there is some point where cost outcomes value and that, at this point, the software development should be stopped. If we can pinpoint this moment, it is the best way to be have a good performance. If a feature is not worth being paid for, it should not be implemented. If no feature is worth being paid for then the development should stop. And it is NO failure if that happens in the middle of the original schedule. Quite the opposite!<br /><br />Jim finished his talk mentioning the Parking Lot Diagram I reproduced below. The diagram very well known in FDD communities focuses on feature releasables. Meaning that, in opposition to the Gantt shart that focuses on tasks, the Parking Lot shows the features that can be released.<br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgS___1kIGuCoyRwDfGs9ZP69c84pJI3rT_liwrCh18JzkP1HMtk71b9FdUnAnhLj6T4I7XoguxP9Daqi25iJ3py_yAHVjtcAYJ59gmyBS66Xp6-Va8ZzqBUFkggTJ2L1Hojpc24luCYRvc/s1600-h/ParkingLotDiagram.png"><img style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer; width: 400px; height: 272px;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgS___1kIGuCoyRwDfGs9ZP69c84pJI3rT_liwrCh18JzkP1HMtk71b9FdUnAnhLj6T4I7XoguxP9Daqi25iJ3py_yAHVjtcAYJ59gmyBS66Xp6-Va8ZzqBUFkggTJ2L1Hojpc24luCYRvc/s400/ParkingLotDiagram.png" alt="" id="BLOGGER_PHOTO_ID_5380174483192699826" border="0"></a>That was it. I've uploaded <a href="http://sites.google.com/site/hugocorbucci/Agile_2009_Zen_Quality_Handouts.pdf">Jim's hand outs</a> for more details.<br />What I learned:<br />Revisiting some ideas that were pretty obvious can help refocus on what really matters. It is good to listen to the same ideas without having a brand (XP, Scrum, FDD, etc.).<br /><br />Please leave your comments and ideas regarding this talk.<br />Next post will be about Alistair Cockburn's keynote.Hugo Corbuccihttp://www.blogger.com/profile/08306316717477317361noreply@blogger.com0tag:blogger.com,1999:blog-1597571711823966454.post-81708681852540229202009-09-10T07:13:00.005-03:002009-09-10T08:47:56.302-03:00Agile 2009 - Day 1 - 24th August - Agile CoachesDuring Monday morning, I was working as a volunteer at Registration. This wasn't as fun as bag stuffing for sure. No big innovations there. Just talking to people, handing bags and shirts. The only ironical part was to received about 6 new items we had to stuff into the bags DURING the morning.<br /><br />For the afternoon, I attended two talks. The one I will be writing about in this post and Jim Highsmith's one about software quality that will be the focus of my next post.<br /><br /><span style="font-size:130%;">"<span style="font-weight: bold;">What Do Agile Coaches Do?</span>" by Liz Sedley and Rachel Davies</span><br /><br />Liz and Rachel started explaining that the session was based on the work they had done to their new book "<a href="http://www.pragprog.com/titles/sdcoach/agile-coaching">Agile Coaching</a>". They also pointed out the session was a workshop and that it was aimed to Carlos - internal coach (see the <a href="http://agile2009.agilealliance.org/personas">conference personas webpage</a> to a better understanding).<br /><br />Their first point was that coaching a software development team was not exactly like coaching a soccer team although the name is the same. It led them towards J. Richard Hackman's work. According to Liz and Rachel, Hackman's book named "Leading Teams - Setting the stage for great performances" out stands from other leadership books because it focuses in teams rather than individuals.<br />From this, they pointed out a couple things that are NOT coaching namely doing someone else's job and directing the team. In opposite, they explained that a coach should provide feedback, explain dynamics, provide suggestions and become useless (they called it: being transitional).<br />They explained Hackman divides possible coaching interventions in three groups:<br /><ul><li>Motivational intervention: one that tries to increase the effort of the team</li><li>Consultative intervention: one that attempts to improve the quality of the process</li><li>Educational intervention: one that aims to improve learning</li></ul>This means that on a Motivational intervention, a coach would take an attitude that would try to have the team (or a member of the team) commit more with the work. That can be achieve by giving her more responsibility regarding that activities or making turning her into the reference or any other thing that would result in an increase of commitment.<br />On an Educational intervention, the coach would run an activity that could allow the team to a better understanding of what is happening and why. Retrospectives usually fit very well in Educational interventions because they make the team think about their situation and look for improvements therefore increasing their learning.<br />A Consultative intervention is one that the coach will apply to adjust the situation to a better one. This is the easiest intervention to make since it only requires that the coach have a suggestion of improvement and use its experience to solve the issue. The problem with it is that it does not helps the team become independent since the knowledge about why applying that solution stays with the coach. On the other hand, this is a very good solution when dealing with a team of novice people (or Shu people - see the Dreyfus learning model or the Shu-Ha-Ri model - I will post about both since there were talks about both) because it will show them one technique.<br /><br />This introduction led us to the workshop itself. The room was split into groups of 3 or 4 people and Rachel and Liz handed over several Scenarios of problems in a team for each group so that the group would suggestion some coaching interventions to each scenario. The activity itself was quite interesting but, as most attendees in the session, I felt just having the division of interventions in 3 kinds was worth the session.<br />Most of the groups reached a fourth division that could be called "Introspection" that consists in any activity that might help understand the problem. Introspection interventions usually lead to Educational interventions from the own team opposed to Educational interventions from the coach (which might have run the Introspection intervention unknowing what the appropriate intervention was). One can argue that Introspection interventions are always performed before any other and therefore can be considered part of each intervention but the point here is that an introspection intervention may result in different sorts of intervention even if the problem is the same.<br /><br />More information can be found in <a href="http://sites.google.com/site/hugocorbucci/a09-AgileCoachesWorkshop-final.pdf">Liz and Rachel's slides</a>.<br /><br />I learned that classifying your actions according to Hackman's suggestion is very useful to self-analysis and to moderate the kind of actions you take. It can also help sharing experience between coaches and can probably be used in some behavioral studies related to cultural differences.<br /><br />The next post will regard Jim Highsmith's "Zen and the Art of Software Quality" presentation. Please leave your comments here and there.Hugo Corbuccihttp://www.blogger.com/profile/08306316717477317361noreply@blogger.com0tag:blogger.com,1999:blog-1597571711823966454.post-43810747691702884442009-09-03T09:05:00.006-03:002009-09-10T07:15:28.798-03:00Agile 2009 - Day 0 - 23th August - Bag StuffingAs a volunteer at Agile 2009, you get to attend the conference without having to pay the conference fee (which is NOT cheap) in exchange for some (~20h) of your working time. Most of this time is spend by helping out during sessions or just in crowd control during the big events.<br />However, there is also some back stage work to be done BEFORE the conference really starts. That is Bag Stuffing.<br /><br />Bag Stuffing is an activity that consists in generating enough conference bags with all sponsor materials within each bag. This year the volunteers received a lot of help from various people and we had the honor of having some Kanban people to help us improve our process as we went on.<br /><br />Our first job was to gather boxes together and discover what should go into each bag. It wasn't the easiest job on Earth since nobody knew the content of the boxes nor if we were missing something or not. It ended up that we had 3 teams. One building up a sample bag with every item they got and counting and checking that every sponsor had their items listed. One building up a redundant bag that would verify that the first team got everything and that we could point each items' boxes. A last team that placed the boxes in a line with a sample item on the top of them so that we could easily identify the piles.<br /><br />This job got done pretty quickly and very soon we had a list of available items and discovered some items were missing and got the news of a few new items arriving. Having included those new items and accounted for the missing ones, the group got split into two groups that would assemble the bags.<br /><br />The process started with 7 people on each group following different ideas:<br /><ol><li>A production line where the bags would flow from one side to the other being moved by the people assigned to stuff in certain items.</li><li>A pick-up line where the people would flow from one side of table to the other filling a complete bag each item at a time.</li></ol>The two groups would then be measured (number of complete bags in 15 minutes) and compared after 4 measures. At each two measures, the teams would have 5 minutes to discuss their process and try to improve it. Just before that, the whole group would get together and talk about the situation.<br /><br />As expected, the team 1 was faster on the first iterations but soon team 2 managed to be more productive. Both team identified a problem with the table's height. However, for security reasons, none was allowed to make the tables higher which resulted in some fatigue to everyone. After the first hour, we had discovered the bottleneck for both teams and, surprise, it wasn't within the teams bounds. The greatest issue was to get the cars full of bags to the upper level and unload them into the registration area. So some people got assigned to that task and some adjustments were made.<br /><br />Team 1 could easily fit the reduction of people by just assigning more items to each person down the line (we already had extra persons in the line). It even managed to have a person (me) dedicated to refilling supplies (lots of times for both teams).<br />Team 2 suffered the loss a bit more since each person less in the team meant a reasonable amount of bags that could flow. But they came out with an improvement to reduce their path. Instead of laying out the tables in a line, they moved them to be a U shape. This way, their path got considerably shorter.<br /><br />It turned out that this was became a problem because the bottleneck would still be getting the bags upstairs but, this time, because the elevators were not as responsive as possible. So Team 1 adapted to this. People would take a small break every time a car got filled up and so they could rest from fatigue.<br />Team 2 also enjoyed it because they were moving around so much (having to go back all the table to restart filling a bag) that they were getting pretty tired.<br /><br />By the end of the morning, both teams had completed around 800 bags and most people left for lunch. I wasn't at the afternoon's work but heard some good improvements from them. The team that picked up line 1 mainly followed what was already being done since it was reasonably simple and effective.<br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEizqx01I8-A2_eC-76P-7gHlUsgfRivXloBgQ6oFcEWnP9sjH_e0d7BEqwFpNFNZ5FUafV8KREnoqJ8wr3R1wbf_ZaoGPzQ_oPCyhoWDqPCvg5KvVcaCNDw4M6lcC9JW_V3EnWwPZDJ3YsT/s1600-h/bagstuffing-tables.png"><img style="margin: 0pt 0pt 10px 10px; float: right; cursor: pointer; width: 72px; height: 37px;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEizqx01I8-A2_eC-76P-7gHlUsgfRivXloBgQ6oFcEWnP9sjH_e0d7BEqwFpNFNZ5FUafV8KREnoqJ8wr3R1wbf_ZaoGPzQ_oPCyhoWDqPCvg5KvVcaCNDw4M6lcC9JW_V3EnWwPZDJ3YsT/s400/bagstuffing-tables.png" alt="" id="BLOGGER_PHOTO_ID_5377282104961646754" border="0" /></a>On the other hand, team 2 identified some very nice improvements. They laid out the tables in the shape of a star (like to image on the right). This way, they managed to dramatically reduce the length of their path to fill a bag, have a quick an big stock of materials and improve their speed. It is also fair to say that it was only possible because they had only 4 people working (they were missing some volunteers).<br /><br />In any way, the results were amazing. About 1400 bags were filled and unloaded from 8am to 3pm by some 20 people in the morning shift and about 12 in the noon shift. Great work from everyone and good lessons from applying Kanban techniques.Hugo Corbuccihttp://www.blogger.com/profile/08306316717477317361noreply@blogger.com0tag:blogger.com,1999:blog-1597571711823966454.post-6410099825293063762009-07-18T21:10:00.007-03:002009-07-19T16:47:30.213-03:00Forget Art! Refactoring viewed as a criticIt has been some time since the last post about the whole <a href="http://codeache.blogspot.com/2009/05/programming-is-maths-but-communicating.html">"Programming is maths but communicating is art"</a>. Since then I've had some very interesting discussions with an architecture critic. She obviously got terrified when I told her I used Wikipedia's Art definition to think about programming and refactoring.<br />It led us to a deeper search of what art is or can be considered. One of the key points Sophia was defending was that we shouldn't give that much value to Art. First because Art, most of times, is not supposed be something nice or pretty. It is supposed to shock, change your view of the world and make you rethink your bases.<br />I'm not going deeper into the discussion "what Art is" because I don't have enough knowledge to argue in it anyway. I'll take Sophia's definition because it will led us to some interesting discussions.<br /><br />So, if Art should change your way of thinking the world, we probably shouldn't want our code to be Art. Pretty much the opposite in fact! Uncle Bob quotes Ward Cunningham: "Clean code is a code that is pretty much what you expected it to be". Well, how can something that is pretty much what you expected make you revalue your life and the world around you? It shouldn't! So any clean code should be the complete opposite of Art and the previous post got it all wrong.<br /><br />So a clean code itself is not Art and the programmers that write it are not artists. However, there is a big deal of work involved into transforming a code that a computer can understand into a code that a human being can understand.<br /><br />Sophia suggested us that analyzing someone's work (including our own) is a critic's work. You observe and analyze the whats, whys and hows someone ended up creating the object of your analysis. You read it, rethinking it, twist it and try to extract every piece of information you can from that thing.<br />Once you believe you have enough knowledge about what you were studying, you write to describe the questions you found about the work. If you manage to achieve a good result, you will provide a very different overview and understanding of the work. You will give it a new meaning that will lead people to understand that work and others from your view point.<br /><br />That was way too abstract so going back to our practical world. Refactoring code is like criticizing it. You understand it and rewrite it offering your own understanding of why that code needs to be the way it is. By refactoring we are not (or should not) change the result of the previous work. In this sense, we cannot really think of it as a creation process. We are obviously producing something just like a critic produces something. But what really matters is the binaries themselves. The fact that the computer can follow those instructions and do what it is supposed to do. We only provide a view point about what, why and how those binaries are the way they are.<br /><br />Accepting this explanation can help us understand a few of the problems we face. First, considering refactoring as a criticism of the code makes it very easy to understand why there is no way to let the code "perfect". It also justifies why programmers should read loads of codes. To be a good critic you have to understand what other critics are saying or said.<br />Another thing that actually fits very well in this description is that refactoring requires the author to have a good capacity to write. You can have an amazing understanding of a work and still be the crappiest critic if nobody can understand what you are saying.<br />At last, it also fits very well Uncle Bob's idea of school of thoughts regarding code. Critics tend to analyze a work according to the knowledge and understanding they have learned from other works or other critics. Those characterize school of thoughts and fit very well the way we feel about coding styles. Java people tend to hate the <span style="font-family:courier new;">return result unless condition</span> style while rubyist find it very natural.<br /><br />I doubt this is the last post about that subject and I hope to get more replies about your opinions and ideas. This is meant to be provide an answer but more likely to point some questions. Would you consider yourself a critic? What are the flaws in that viewpoint? Do you have another parallel to make?Hugo Corbuccihttp://www.blogger.com/profile/08306316717477317361noreply@blogger.com4tag:blogger.com,1999:blog-1597571711823966454.post-8140310239046002422009-05-12T08:55:00.015-03:002009-05-12T19:40:03.725-03:00Programming is maths! But communicating is art...I tried to sum up the contents of this post (which will surely be long) in the title.<br /><br />The discussion came up yesterday after the master's thesis presentation of a friend of mine (<a href="http://agileandart.blogspot.com/">Daniel Cukier</a>). His proposal was way too unconventional to pass easily. During the teachers' comments on his thesis, <a href="http://www.ime.usp.br/%7Evwsetzer/">Prof. Valdemar Setzer</a> pointed out that he disagrees on Daniel's sentence that said (from my memory that is brief and unprecise) "The art of programming ...".<br />Prof. Setzer says he disagrees with Knuth (and Daniel) on the fact that programming is an art.<br /><blockquote>"Programming is formalizing your ideas in order to make a computer execute them and, therefore, cannot be considered art since it must not be done or influenced by your subconscious and must be an activity on which you are always conscious of your actions."</blockquote>This is yet another imprecise and crappy translation of what happened but it does not matter. The idea is mainly that if we need to be fully conscious of all our actions when programming, then this activity cannot be considered art since art relies heavily on one's subconscious.<br /><br />The whole deal led us (me and Mariana Bravo) to a discussion about what part of what we do is art. Because, obviously, both of us believe that some part of it <span style="font-weight: bold;">IS</span> art. We couldn't disagree with Prof. Setzer. Indeed, talking to a machine is pretty much the opposite of art. Formalism, logic and maths are key elements to be used very consciously to achieve the goal of writing something that compiles and run as expected in a computer. From this I conclude that <span style="font-weight: bold;">writing to execute is not art</span>.<br />I also claim that this is also the part of computer science that is very well mastered! Programmers are great to <span style="font-style: italic;">write something that execute and does what was wanted</span>.<br /><br />You can see the proof to this claim on every programming competition out there. <a href="http://cm2prod.baylor.edu/welcome.icpc">ACM-ICPC</a>, <a href="http://www.hackday.org/">Yahoo HackDay</a>, <a href="http://code.google.com/codejam">Google Code Jam</a>, <a href="http://imaginecup.com/">Imagine Cup</a> and many others. Those competitions stress this aspect of computer science. They expect the people involved to write a software that executes and does what was expected. And people do GREAT! I have seen amazing codes, amazing solutions and wonderful applications being built on those contests. Yet, every company involved in those contests (to hire the winners) still fights to write better software and are present in tons of conferences trying to achieve better results. The winners of those contests are usually amazing programmers in the sense that they are great to find solutions to a problem and have it compile and run. Why are we still struggling to write better software then?<br /><br />The answer is not mine. It has been around for ages and loads of people probably already said it before me (and probably much better than me): "Because the greatest problem of software is the <span style="font-weight: bold;">maintenance</span>".<br />During the maintenance, it is no longer THAT important to talk to the machine. The code is already talking to the machine somehow and some part of it should be saying something different. The code now enters a whole new realm. <span style="font-weight: bold;">The realm of talking to people</span>.<br /><br />Having your code talk to people is very similar to having a letter or an email or even a blog communicating your ideas. One could argue that writing with code is bounded to a formalism that breaks the communication and beauty that can be achieved. To which I reply that, for many years, poetry bounded itself to very rigid forms such as <a href="http://en.wikipedia.org/wiki/Alexandrine">Alexandrine</a>, <a href="http://en.wikipedia.org/wiki/Iambic_pentameter">Iambic Pentameters</a>, <a href="http://en.wikipedia.org/wiki/Dodecasyllable">Dodecasyllabes</a> and others. I believe I can say that nobody would dare deny that there is great art done following those rigid rules.<br /><br /><a href="http://www.objectmentor.com/omTeam/martin_r.html">Uncle Bob</a> says in his <a href="http://www.google.com.br/url?sa=t&source=web&ct=res&cd=1&url=http%3A%2F%2Fwww.amazon.com%2FClean-Code-Handbook-Software-Craftsmanship%2Fdp%2F0132350882&ei=-msJSrCdBZSEtwePyYzfCw&usg=AFQjCNHR62yE9_f-EXjfGyx8aKcovzjKHw&sig2=3in_1hsvYNvzjWE1ftfAjA">Clean Code</a> book: "A good and clean code should read as a newspaper article". He says so because he believes this is the only way one can be quickly parse a code and focus only on what is important to the current matter. It means that complexity should be hidden as much as possible to avoid having to bump into her all the time. It also means (indirectly) that there are TONS of ways to write the same code, that is, to achieve the same computer execution result.<br /><a href="http://fr.wikipedia.org/wiki/Raymond_Queneau">Raymond Queneau</a> is a famous french writer author of "<a href="http://fr.wikipedia.org/wiki/Exercices_de_style">Exercices de styles</a>" (Style exercises) and many others. His book presents 99 versions of the same story written in the same language (French) with different styles. Each of the versions have different writing styles and present the reader with a new experience of the same facts. Writing the book was surely an amazing exercise but reading it is also very interesting. Reading 99 ways to achieve the same result makes you think a lot about what you actually write.<br /><br />As programmers, we are subjected to such exercise very often. There are dozens of frameworks to achieve the same goal (many times in the same language), there are dozens of libraries that do the same thing but the code is ALWAYS VERY different.<br />I propose (and will try to) that, as programmers, we force ourselves to take part of this exercise. Our version control systems help to do so and we should be doing it all the time. Write a first version of your code, save it (commit), write a new version of your code (maybe from the first one or not), save it and repeat the action.<br /><br />Such description of the thing makes me (and you, probably) remind that we already to this over and over and over. Refactoring is exactly the process to rewrite to achieve the same goal but changing the <span style="font-style: italic;">style</span>.<br /><a href="http://martinfowler.com/">Martin Fowler</a>'s definition of <a href="http://martinfowler.com/books.html#refactoring">Refactoring</a> is "a change made to the internal structure of software to make it easier to understand and cheaper to modify without changing its observable behavior". It is not really the same thing I previously stated right? This is where the art comes along.<br /><br />Here is Fowler's <span style="font-style: italic;">trick</span>: "... to make it easier to understand and cheaper to modify...". This definition is amazingly vague! How the heck do you make something get easier to understand or cheaper to modify? <span style="font-weight: bold;">Formally</span> you don't! You can only find out what makes the code easier subjectively. You can only know what makes it cheaper to modify when you actually have to modify it and do it.<br /><br />Uncle Bob uses the same <span style="font-style: italic;">trick</span>. He says Clean Code helps you write better code and detect bad code. Again, this is highly subjective! And more: it depends heavily on the programmer's ability to communicate through the code with other people. Such ability is heavily related to art!<br />According to Wikipedia (and please feed me better info if you have them),<br />"<a href="http://en.wikipedia.org/wiki/Art">Art</a> is the process or product of deliberately arranging elements in a way that appeals to the senses or emotions".<br />Again from Wikipedia, "Communication can be perceived as a two-way process in which there is an exchange and progression of thoughts, feelings or ideas towards a mutually accepted goal or direction".<br /><br />From those definitions, I would say Art is a form of Communication. Moreover Poetry, Literature, Theater, Painting, Sculpting, Music, Dance and other art activities are holders to a communication channel between the artist and the watcher.<br />Poetry and Literature use words.<br />Theater and Dance use the human body.<br />Painting and Sculpting rely on colors and textures while Music bases itself on sounds.<br /><br />The study of art is therefore heavily related to the study of how to communicate with people from various backgrounds and ideas. This is the art matter that is missing in the computer science courses (at least the one I followed) and the computer related careers.<br /><br />Regarding literature, someone can put a word after another and make it "run", that is, make sense. But it takes a lot more effort to pass from that to art.<br />Programming follows the same rule.<br />Loads of programmers can put an instruction after another but it takes an amazing work to transform that into something that will communicate later on.<br /><br />My conclusion from this post (more an article than a post) is that computer science courses are very important because they teach you to communicate with the computer. But once you learned (and it takes more time than just the course) to make the computer do what you want, you must learn to communicate with people. Actually, you should probably do both at the same time but the important part is that you always remember that "executing" is poor and communicating can be art.<br /><br />Now all that I need is to actually incorporate such thinking and begin acting to improve in this sense.Hugo Corbuccihttp://www.blogger.com/profile/08306316717477317361noreply@blogger.com7tag:blogger.com,1999:blog-1597571711823966454.post-83580880343199860992009-03-26T12:52:00.006-03:002009-03-26T15:29:35.509-03:00Developing for ArchimedesHello,<br />With the new team working on Archimedes, I had to help them set up an environment to work with Archimedes. I am pretty proud of the outcome.<br />In order to code for Archimedes, just follow these steps:<br /><ol><li>Download and install a Java Virtual Machine S.E. SDK version 1.5 or later compatible with the Sun virtual machine (I suggest sun's one called 'Java SE Development Kit (JDK)' under <a href="http://java.sun.com/javase/downloads/index.jsp">http://java.sun.com/javase/downloads/index.jsp</a>).</li><li>Install Subversion (<a href="http://subversion.tigris.org/">http://subversion.tigris.org</a> - or "sudo apt-get install subversion" on debian based linux distributions or "sudo port install subversion" on Mac OS X with MacPorts).<br /></li><li>Download an Eclipse version above 3.4 (I suggest the one found at <a href="http://download.eclipse.org/eclipse/downloads/drops/R-3.4.2-200902111700/">http://download.eclipse.org/eclipse/downloads/drops/R-3.4.2-200902111700/</a> - Eclipse SDK for your platform should be enough). Make sure it has all of the Eclipse RCP plugins. If you pick another version, choose the package Eclipse SDK or the specific build for Eclipse Plug-in Development.</li><li>Install it on your system. It usually just involves unpacking the zip or tar.gz file you downloaded.</li><li>Open it. Usually, just enter the folder that was created on the previous step, there should be an executable called 'eclipse'. Run that executable.</li><li>Install subclipse. Go to "Help"->"Software Updates...". Select the tab "Available Software", click on "Add Site...". Fill in the "Location" field with "http://subclipse.tigris.org/update_1.4.x" (if you installed version 1.6 of Subversion, you can use "http://subclipse.tigris.org/update_1.6.x"). Click on OK. It should list the site on the table with the name "http://subclipse.tigris.org/update_1.4.x". Click the checkbox next to it. Click on the button "Install..." on the upper right corner. Accept the license and let it install. Once it's done, it will ask you to restart Eclipse. Please do.</li><li>Download the file "<a href="http://svn.archimedes.org.br/public/mainarchimedes/rcparchimedes/br.org.archimedes.config/trunk/ArchimedesProjectsSet.psf">http://svn.archimedes.org.br/public/mainarchimedes/rcparchimedes/br.org.archimedes.config/trunk/ArchimedesProjectsSet.psf</a>". Save it somewhere you can find.</li><li>Go back to Eclipse and go to "File"->"Import...". Expand "Team" and choose "Team Project Set". Click "Next". Click "Finish". It will download all the projects needed to work on Archimedes. This will take some time and a lot of bandwith. If you get an "Svn error", please erase all projects and try again.</li></ol>That's it. Once you've done that, you should have about 100 projects for Archimedes. If you are getting some compile errors ("there are red signs on the projects"), try changing your Java default compile version. To do so, go to "Window"->"Preferences..." (or "Eclipse"->"Preferences..." on Mac), type 'compiler' , select the "Compiler" item on your left pane, change the "Compiler compliance level" to "1.5". It should rebuild the project and remove the compiler errors.<br /><br />Running Archimedes from within Eclipse should be pretty simple but I've found problems more than once. Here is what you should do:<br /><ol><li>Find the project "br.org.archimedes.core", expand it. Find the file "archimedes.product", right-click it, "Run As..."->"Eclipse Application". On Mac, that's enough. It all works. On Linux, I've found that this doesn't select all plugins needed. It then pops an error dialog asking if you want to view the log. Answer "No".</li><li>Go to "Run"->"Run configurations...". Select the tab "Plug-ins". Click the button "Add Required Plug-ins". Click "Apply" and then "Run". This should do the trick and run Archimedes with all plug-ins.</li></ol>Ok! This should be enough to work on Archimedes and try your modifications. Last and final step to have a complete Archimedes environment: setting up the build system. This also got greatly improved. The following steps should be enough:<br /><ol><li>Download an Eclipse version along with its Delta Pack. I suggest you use the same version on development and on building to avoid unpleasant surprises. Therefore, go to <a href="http://download.eclipse.org/eclipse/downloads/drops/R-3.4.2-200902111700/">http://download.eclipse.org/eclipse/downloads/drops/R-3.4.2-200902111700/</a> and download "Eclipse SDK" for your platform and "Delta Pack". Extract both files on the same place (it should merge the contents). This means, if you enter the "eclipse/plugins" directory of that new eclipse path, you should find plugins for all platforms (such as "org.eclipse.swt.carbon.macosx_3.4.0.v3448f.jar", "org.eclipse.swt.gtk.linux.ppc_3.4.0.v3448f.jar", "org.eclipse.swt.gtk.linux.x86_3.4.0.v3448f.jar",<br />"org.eclipse.swt.win32.win32.x86_3.4.0.v3448f.jar" and others).</li><li>Go to your "br.org.archimedes.build" project. Open the "build_local.properties" file. Change all fields. "buildHome" should be the absolute path to your "br.org.archimedes.build" project. "buildDirectory" should be the absolute path to a temporary folder where the build will generate the files. Make sure this is not a folder where you store important files because the build system will erase it. "eclipseDir" should be the absolute path to the Eclipse installation created on step 1. "os" should be the name of your operating system ("linux", "macosx" or "win32"). "ws" should be the name of the widget system of your system ("gtk", "carbon" or "win32"). "arch" should be the architecture of your processor ("x86", "x86_64" or "ppc").</li><li>Go to your "br.org.archimedes.build" project and open the folder "maps". Copy the file "all-hugo.map" to "all.map". Open the new "all.map". Replace all occurrences of "/Users/night/Document/Archimedes/" with the path to your workspace (for example "/home/night/" if my workspace if "/home/night/workspace").</li><li>On Eclipse, right click the "build.xml" file on "br.org.archimedes.build" project and choose "Run As..."->"Ant Build". On other systems, open a terminal (or cmd.exe), go to the directory where you "br.org.archimedes.build" project is and type 'ant'. If "ant" is not installed, please install it (<a href="http://ant.apache.org/manual/install.html">http://ant.apache.org/manual/install.html</a> or "sudo apt-get install ant" for debian based linux distributions). This should trigger the build process. It takes around 5 minutes to build it all.</li></ol>On the folder you specified for "buildDirectory", you should find a folder "results" that contains several files. Among them, "Archimedes-<current_version>-<os>.<ws>.<arch>.zip" files for macosx, linux (x86 and x86_64) and windows. Those are your executables.<br /><br />Happy hacking!</arch></ws></os></current_version>Hugo Corbuccihttp://www.blogger.com/profile/08306316717477317361noreply@blogger.com6tag:blogger.com,1999:blog-1597571711823966454.post-17951757549360599852009-03-26T12:20:00.003-03:002009-03-26T12:47:33.506-03:00The silence of the lambs on ArchimedesIt has a been a while since no news were posted, but, as in the movie, silence doesn't mean nothing is happening. Actually, quite a few things happend since the last post.<br /><br />First, a new team of 6 undergrad students is working on Archimedes again. As for the past 4 years, they'll work on Archimedes as part of an eXtreme Programming laboratory course. This semester's goal is "Portability".<br />I'll have them focus on making Archimedes compatible with other software. This basically means file support for SVG (exporting only for now -- in order to have post project work on <a href="http://www.inkscape.org">Inkscape</a>), native support to DXF (importing and exporting without file losses -- should allow to work with most of other CAD systems) and working on a few more essential elements such as Spline and Groups. I've also asked them to finish the work that was started on Trim, Extend and Fillet. I am not sure they will manage to do it all, but I'll help them the way I can so we might actually do it.<br /><br />Other than that, I am happy to say <a href="http://www.archimedes.org.br">Archimedes' new website</a> is pretty good. It is currently pretty featureless but I intend to improve this with time. My next step is to add a release system plugged into the repository in order to easily generate new versions of Archimedes. If I manage to do it by April, 1st, I'll use it to release the new version with several improvements. For now, please report or request anything you want from Archimedes in the <a href="http://www.sf.net/projects/arquimedes">SourceForge website</a>. I hope to remove this dependency with the new website but it will take some time.<br /><br />Less exciting news. I recently discovered that Archimedes had a few licensing issues. I've spent two months trying to get in touch with every code contributor of Archimedes so far to change the License of Archimedes and had a partial success. The output is: Archimedes cannot be <a href="http://www.gnu.org/licenses/">GPL</a> (any version) because it uses code licensed under <a href="http://www.eclipse.org/legal/epl-v10.html">EPL v1.0</a> and changes it, which would mean it should be licensed under GPL which isn't allowed by the EPL license. Therefore, Archimedes code is now licensed under EPL. The only implication of this change is that Archimedes' code is no longer as viral as GPL code so people can use parts of it on commercial application as long as they keep Archimedes' code free. This change also implied that every project of the current Archimedes project is now distributed with a License.TXT file. I was also forced to create a small <a href="http://rubyforge.org/projects/header-inserter">header-inserter ruby script</a> which I made available at rubyforge as a library. The library makes it really easy to list all files within a directory that match a certain pattern and also retrieves subversion data for each file if there is one. The code can also be found at my <a href="http://github.com/night">github page</a>.<br /><br />Last notice, Jhonny warned me that it wasn't clear which page of archimedes should be check. Please, always refer to <a href="http://www.archimedes.org.br">www.archimedes.org.br</a>! The incubadora's page is abandoned. Their link is awful and the support is getting thinner and thinner so I guessed it would be better to handle ourselves. That's it for now.<br />More news soon with the new version.Hugo Corbuccihttp://www.blogger.com/profile/08306316717477317361noreply@blogger.com1tag:blogger.com,1999:blog-1597571711823966454.post-3053551603718610592009-01-14T09:48:00.003-02:002009-01-14T10:04:48.977-02:00Holidays are over and new archimedes versionHello everyone,<br />The end of the year is always complicated. This year I had an extra since I am trying to move to new apartment. Luckily, to plan my move, I wanted to have a plan of the place and this sent me back to Archimedes. When I tried to use it, I discovered several bugs that stopped me from working. So I spent a pretty good amount of time solving some of those problems.<br /><br />So I've just release a new version with several of those fixes. I have already discovered 4 others bugs in this unstable version and I am working to fix them. I am also working on PDF exporting system again. Most of the code just needs to be adapted and a few classes for the eclipse's system. Extend is also on going but I am not sure I will manage to distribute it on the next stable version without delaying too much.<br /><br />I also closed (removed all files from) the repository on https://archimedes.incubadora.fapesp.br/svn/ and let a file saying that everything (including the history) has been moved to http://svn.archimedes.org.br/public/.<br />This should improve the overall bandwith and allow me to trying and implement a few features on the archimedes website (which is pretty stalled right now).Hugo Corbuccihttp://www.blogger.com/profile/08306316717477317361noreply@blogger.com12tag:blogger.com,1999:blog-1597571711823966454.post-44540233447210119692008-10-27T12:32:00.003-02:002008-10-27T12:50:05.667-02:00Tuesday at OOPSLA'08Tuesday I managed to seen a bit less things from the conference since I had to work as part of my student volunteer program for most of the day. I managed to see the opening keynote and at the end of the day, have a session of traditional <a href="http://http://groups.google.com/group/dojo_sp/web/CodingDojoSP-2008.pdf">Coding Dojo</a>.<br /><br />The opening keynote was from an archeologist named Mark Lehner who dedicated over 30 years of his life to the history of Egypt. He had a long talk about the way the pyramids are viewed and his search for the city that existed to support the pyramids constructions. Aside from several very interesting information about archeology and the way archeologists work, his talk showed how <span style="font-style: italic;">modular</span> the city that built the pyramids was. Amazingly, the houses of the workers were all pretty much the same several times replicated as <span style="font-style: italic;">instances of a model</span>. He also showed that the hierarquical structure among the builders was the same as in every social organization where roles were different acording to the structure where you were, or simply <span style="font-style: italic;">polymorphic</span>.<br /><br />All this is interesting and shows the ideas we have nowadays are not even close to be new and have been used over and over. Reassuring but no big deal to me. What amazed me was that those things only happend in the city that built the pyramids and the people in it. The pyramids themselves not modular or polymorphic at all. They are carefully hand crafted to and not slightly modular. I don't know yet what to take away from this information but it sure sounds like something we should think about.<br /><br />During the day I did a few volunteers task. I ended my day by attending to the Coding Dojo session. First of all, I wish people with the <a href="http://dojotoolkit.org/">Javascript library called 'dojo'</a> would rename their project to something more appropriate. According to their own website, 'dojo' is just a name that won't get them sued. Coding Dojos actually do have a reason to be called as such and I had a few people coming over thinking we were going to talk about the library which is somehow anoying. Anyway, we had a small group (4 people including me and Mariana) and we attacked the <a href="http://acm.uva.es/p/v101/10189.html">Minesweeper problem</a> in Java. We managed to code a solution but we were not really very pleased with it at the end. Mostly because we only had two tests (although we had a 100% coverage) and we took some very big steps during the solution. This is a very common outcome for a first session of a Coding Dojo. Feeling which tests will result in a major step is something that does not have (yet?) a <a href="http://codeache.blogspot.com/2008/10/crystal-monday-morning-at-oopsla-2008.html"><span style="font-weight: bold;">Shu</span> or <span style="font-weight: bold;">Ha</span> description</a> and is usually learned with practice and time.<br /><br />That's about it for Tuesdays. I'll post a bit about the following days later on this week.<br />Enjoy yourselves.Hugo Corbuccihttp://www.blogger.com/profile/08306316717477317361noreply@blogger.com1tag:blogger.com,1999:blog-1597571711823966454.post-67106891280125426102008-10-27T11:58:00.005-02:002008-10-27T12:31:37.447-02:00Empty open spaces at OOPSLA'08Hi again,<br />I spent most of Monday afternoon at the Open Space area at OOPSLA. Open spaces are a very interesting concept to get people gather around a subject. It is based on the fact that it is much more useful to have a conversation than a monologue. Therefore, traditional presentations are less useful than getting people together to chat with each other.<br /><br />So what you need to have an open space?<br />Well, space, a big board, a few tables, a lot of chairs, flip charts and, maybe, just maybe, one projector. On the big board, write down a time schedule with several areas available (places with chairs and a table) and provide a way for people to suggest their topics.<br />After that, you need to warn people about a few things. There are 4 rules on open spaces and one law. The rules are:<br /><ol><li>It starts when it starts<br />This means that people can be late, people can just post and sit and start talking or people can start it before or after the time schedule.</li><li>Those who attend are the right persons<br />Whoever comes in is welcome and should be there. No matter if that person does not know much about the subject or is an expert. A lot of very interesting things can be achieved by just gathering people that know very little about a subject but are willing to spend some time thinking about it.</li><li>Whatever happens was the only thing that could have happened<br />If the output of the meeting is that this subject is useless to be discussed, so be it. It is still a very good thing to learn. If, on the other hand, you decide that the people there are more interested in something else and you change themes, great too!<br /></li><li>It ends when it ends<br />There is no need to speed or slow people to finish on schedule. If the subject has not been fully discussed, stay. If it has, go. Nothing to worry about.<br /></li></ol>The law is called "The law of 2 feet" or "The law of mobility". It states that if you are not giving to or receiving from anything of that open space session, then leave. It is understood and expected that people only stay if they are passionate about what is being discussed. This allows people to leave a group freely at anytime therefore keeping the group always happy about the ongoing discussion. The two feet come from a foot of passion and one from responsibility which should allow you to leave if needed.<br /><br />This also allows for two specific behaviors. The first one is the butterfly one which consist of flying around the spaces just to check what is going on without participating actively or staying anywhere. Those can generate new subjects when meeting another of their species. The second one are the bumble bees. Those go around each conversation and sit for a while, engage in the discussion and then leave to another area. Those ones allow for information and different perspectives to flow across the areas. Both should be welcome and accepted in an open space environment.<br /><br />This was the first year OOPSLA had an open space are. Dirk Reihle was responsible for that but, sadly, he got stuck in Germany trying to get his work visa to the US. Luckily enough, Deborah Hartmann was there to replace him. Since OOPSLA's open activities really only start on Tuesday, the area was quite empty on Monday afternoon and the Coding Dojo session I had suggested with Mariana ended up empty. We then decided to help Deborah in creating an interactive poster to present the Open Space during the poster presentations at the ice breaker reception later that day. We came up with a three areas poster: What is an Open Space? - The schedule for Tuesday, Wednesday and Thursday - What questions would you like to have answered by Friday?<br />The idea was to get both people aware of open spaces and people that had no idea what it was to collaborate in order to create new sessions. And indeed, during the reception, we managed to get some people to suggest topics and get interested in the topics that are posted. And that closed Monday around 9pm and we went straight to bed to sleep.<br /><br />That was it for Monday. If you have ever been to an open space and would like to give a better description than mine, please do so in the comments here or post a link to your blog. If you would like to have an open space going, contact me or post a comment and I can try to help or get you in touch with other helpers.Hugo Corbuccihttp://www.blogger.com/profile/08306316717477317361noreply@blogger.com0tag:blogger.com,1999:blog-1597571711823966454.post-53736163051428204382008-10-27T11:09:00.007-02:002008-10-27T12:58:50.348-02:00Crystal Monday morning at OOPSLA 2008Hello,<br />As always with OOPSLA, once it starts it is very hard to keep anything updated since we get so busy. Monday was an interesting day.<br /><br />I had to pleasure to attend to <a href="http://alistair.cockburn.us/">Alistair Cockburn</a>'s tutorial called <a href="http://www.amazon.com/Crystal-Clear-Human-Powered-Methodology-Development/dp/0201699478">Crystal Clear Methodology</a>. As I expected it was very interesting. Alistair's work is well known and I am surely not the best person to talk about it but I will try anyway. Although I already heard about the <a href="http://en.wikipedia.org/wiki/Shuhari">Shu-Ha-Ri </a>levels of knowledge (that are not that far from Apprentice-Novice-Expert-Master from the <a href="http://blog.bruceabernethy.com/post/The-Dreyfus-Model-of-Skills-Acquisition.aspx">Dreyfus model</a>), it is always better the have them explained from someone that know them very well.<br />The idea is that the <span style="font-weight: bold;">Shu</span> level of knowledge is the one where you want to learn the basis. It basically means you want a recipe that can help you get the thing done without having to give it much thoughts. This is how you learn most of the things in life: reading, writing, riding a bike, cooking, programming and those sort of things.<br />Once you are comfortable at reproducing those steps, you want to have a better understanding about why the best practioners in the fields do it differently from time to time. You then pass to the <span style="font-weight: bold;">Ha</span> level. In this level, you get to collect all sorts of techniques in the field you are learning. This is when you learn the exceptions, the cases, the workarounds and stuff like that. If you take the learning to ride a bike example, this is when you can take those auxiliary wheels off and do those nice curves all by yourself. You might also learn how to straight your bike and have it running on just one wheel.<br />When you get to master those several techniques, you get to understand how or when to use one technique or another. At this level, you are reaching the <span style="font-weight: bold;">Ri</span>. From then on, you can pick techniques according to the context. Your answers to any question become "It depends..." and very slight changes in the environment can make you change radically the way you do things. At this level, you might even inovate with new solutions that you never really thought about, they just <span style="font-style: italic;">feel</span> right.<br /><br />If you are familiar with the Dreyfus model of knowledge, you can see very clearly that those are very closely related ideas. It is interesting to perceive how the transitions in this model are more <span style="font-style: italic;">fluid</span> or, let's say, more oriental opposing to the transitions in the Dreyfus model being more occidental. More on those differences to come on the next posts.<br /><br />The rest of Alistair's tutorial showed how XP (first edition) and Scrum are excelent <span style="font-weight: bold;">Shu</span> descriptions of Agile methods although the author are clearly at the <span style="font-weight: bold;">Ri</span> level themselves. XP (second edition) and the Crystal family, on the other hand, are, according to Alistair, better suited at the <span style="font-weight: bold;">Ha</span> level since they present a set of possible solutions according to a given environment. I personally don't think the <span style="font-weight: bold;">Ri</span> level can be learned with a book which makes me believe that we can't go much further than Crystal in the matter of describing Agile methods if Alistair is right.<br /><br />There was much more content on Alistair's talk but you can learn most of it from his books.<br /><br />That was it for Monday morning. More posts comming with the rest.<br /><br />See you all!Hugo Corbuccihttp://www.blogger.com/profile/08306316717477317361noreply@blogger.com0tag:blogger.com,1999:blog-1597571711823966454.post-43784173755795011202008-10-19T17:41:00.003-02:002008-10-19T17:57:01.275-02:00First day at OOPSLAHello,<br />I am currently attending <a href="http://www.oopsla.org">OOPSLA 2008</a> at Nashville, Tennessee in the USA. This is the second year that I am a student volunteer at OOPSLA. This year, there are much fewer attendees and, as far as we know, it is the financial crisys' fault.<br />So far, it has just started. Registration went pretty well this morning and tutorials are going OK so far. No big deal and we are yet waiting for the special talks. I would highlight Dick Gabriel's photography course that will be going on during the whole conference. Tomorrow we'll have Alistair Cockburn talking about Crystal in the morning and effective agile use cases in the afternoon. I will surely attend to the first one. I might join the second one although I might go to the Design Pattern: Next Generation's workshop by Brian Foote, Dirk Riehle and Joshua Kerievsky. I was slightly disapointed by this year's program.<br /><br />Two news that were supposed to be secret but are not. The first one is that next year's OOPSLA will be held at Orlando, Floripa at some hotel inside Disney World. This means I probably won't attend it because hotels will be pretty expensive and flights will be overbooked way ahead so I don't think I'll make it. The second "secret" is that the special event will be held at the <a href="http://www.nashville.gov/parthenon/">Parthenon</a> replica in Nashville. I'll try to have Mariana's photos to post them here when we can.<br /><br />That's it for now. For those of you who still want Archimedes news, please wait another week or two until I manage to get my time schedule back to regular shift. See you all.Hugo Corbuccihttp://www.blogger.com/profile/08306316717477317361noreply@blogger.com0tag:blogger.com,1999:blog-1597571711823966454.post-84782133664124353082008-10-14T14:19:00.005-03:002008-10-19T14:21:24.698-02:00Coding Rumors++ or UberDojoHello,<br />I previously described the <a href="http://codeache.blogspot.com/2008/09/coding-rumors-or-telephone-coding-game.html#links">Coding Rumor</a> game and later on presented the results we had at <a href="http://codeache.blogspot.com/2008/09/pycon-brazil-summary.html#links">PyCon Brasil 2008</a> doing it. During the <a href="http://codeache.blogspot.com/2008/10/encontro-agil-was-success.html#links">Encontro Agil</a>, we tried having a session of what <a href="http://www.isnomore.net/">rbp</a> (or R) called UberDojo to follow the UltraDojo idea (the name he prefered for Coding Rumor).<br />Just to remind you, UltraDojo (or Coding Rumor) is a Coding Dojo session where you don't need a projector. The code is written in one laptop and the pair switches with rounds just like the regular one. Everyone works on the same problem but you only get to see the code for 2 rounds (14 minutes) in which you are the co-pilot and then the pilot. If you are not on any of those roles, you can chill and chat with other people. The advantage of this is that it requires less time focusing on the problem which makes it a good practice for conferences.<br />The UberDojo version is just the UltraDojo game with several laptops. You should plan to have at least three people for each laptop but you can have more if you want. In this case, when the pilot leaves, he goes to the "audience" and will choose another laptop to go to on the next round.<br /><br />Last Monday's session happened at Thiago's house. We were 14 people (<a href="http://www.dtsato.com/blog">Danilo Sato</a>, <a href="http://nutrun.com/">George Malamidis</a>, <a href="http://www.isnomore.net">Rodrigo Bernardo Pimentel</a>, Thiago Colucci, Fabricio Sousa Nascimento, Jacqueline Marchetti, <a href="http://blog.seatecnologia.com.br/">Renato Willi</a>, <a href="http://expressocapital.blogspot.com/">Bruno Pedroso</a>, João Pedro Kerr Catunda - a.k.a Yoshi, Mariana Bravo, <a href="http://www.vidageek.net">Breno Flesch, Rafael Schouery</a>, Adolfo Rodrigues and myself). We had four laptops splitted in two round tables. Each table defined a language (<a href="http://www.haskell.org/">Haskell</a> and <a href="http://www.ruby-lang.org/">Ruby</a>) and each side of the table defined a problem (<a href="http://codingdojo.org/cgi-bin/wiki.pl?KataBankOCR">Bank OCR</a> and <a href="http://acm.uva.es/p/v101/10189.html">Minesweeper</a>).<br />We followed 7 minutes rounds and tried to keep Haskell and Ruby "experts" available to help out people programming. At the end of each round, the co-pilots would become pilot, pilots would go away and part of the audience would join as a co-pilot on each table. We tried to keep it as random as we could in order to never repeat pairs. We had over 1 hour coding that way. It was very intense and fun. Obvisouly, we never got to finish any problem although we walked pretty well with the Haskell OCR system.<br /><br />All the produced source code is available at <a href="http://www.github.com">Github</a> on the <a href="http://github.com/dojosp/participant-s-projects/tree/master/">dojo project</a> at UberDojo-02. In retrospective people reported that is was very exciting and that it was actually a good teaching system but that they should police themselves to actually explain quickly the code to the newcomer before starting to code and be even more radical with the baby steps approach. I think this might be a very good exercise for experienced TDDers and agile teams. I believe if a team manages to actually code something slightly more complicated than <a href="http://rubyquiz.com/quiz22.html">Roman to Numerals</a>, it is actually showing a lot of code cleaness. We acknowledge, however, that this sort of exercise is not especially welcoming to new people and requires quite a few experience with TDD. We agreed to have a UberDojo once a month in our meetings and keep the rest as regular dojo sessions. If you try it, please let me know what went right or wrong and your impressions.<br /><br />Thanks and bye bye.Hugo Corbuccihttp://www.blogger.com/profile/08306316717477317361noreply@blogger.com1tag:blogger.com,1999:blog-1597571711823966454.post-20283484044807813242008-10-13T08:52:00.006-03:002008-10-13T09:44:37.931-03:00Encontro Agil was a success!Hello everyone,<br />On Saturday, we (<a href="http://www.agilcoop.org.br/">AgilCoop</a>) ran the first 2008 agile conference in Brazil (although <a href="http://www.thedevelopersconference.com.br/">TDC</a> had quite a few agile talks, the focus was not in agile). The <a href="http://www.encontroagil.com.br/">Encontro Agil</a> (or Agile Meeting) happened at the <a href="http://www.ime.usp.br/">IME</a> (Instituto de Matemática e Estatística - Mathematics and Statistics Institute) of <a href="http://www.usp.br/">USP</a> (University of São Paulo). The event was free (as in free beer). We had around 200 attendees, 16 speakers, 2 debates and a free lunch.<br />We followed several ideas from the <a href="http://www.agile2008.org/">Agile 2008</a> conference. We had an ongoing retrospective on a wall between the two main rooms, we had an open spaces room that was interesting but quite empty since people are not used to those ideas, we had a birds of a feather session with 5 rooms discussing several topics and a huge updatable conference schedule.<br /><br />On the overall, the feedback was great. Some things people pointed out in the retrospective board: we have to have more coffee, especially in the morning and after lunch. There was a load of information to be absorbed in too little time. Maybe increase the conference size or reduce the amount of information on each talk. Hand-over material has to been better selected.<br />On the other hand, people loved the agility in the event. We had to find a replacement talker (that was me) because another talker (Jorge) was late and the talk ran quite nicely. We adjusted the schedule on the fly to allow Jorge to give his talk anyway. The free lunch was one of the great points and birds got a nice feedback too since interaction is nicer than just listening.<br /><br />A few statistics of the event. We had almost 500 people that registered themselves to come. From those, only around 300 confirmed their participation on the event a couple days before. And we had 200 attendees which gives us something around 60% drops from the original registration. As it is frequent on computer science conferences, we had 16% female attendees. Around 80% of the public was either a manager or a developer and had between 25 and 45 years old. We also had 41% of the attendees that had no experience with agile methods and 43% that were novice to it (had less than 1 year of experience). To my information, 60% never contribute to free software projects and 25% contribute occasionally. Finally, music is the extra-curriculum activity that most people practice (44%) and/or would like to learn more (48%) followed closely on the learning wish list by dance (35%).<br /><br />I guess this is it for now. We will have all the content of the advanced talks on the web and a few videos of the event published around. I will post those when they are available. All slides should be available at the <a href="http://www.agilcoop.org.br/">AgilCoop web site</a> in a few days as well as on the <a href="http://www.encontroagil.com.br/">conference's web page</a>.<br /><br />Future conferences in Brazil that will have some agile content are <a href="http://www.locaweb.com.br/railssummit/">Rails Summit Latin America 2008</a> organized by Locaweb and mainly <a href="http://www.akitaonrails.com/">Fabio Akita</a> and <a href="http://www.caelum.com.br/falando-em-agile/">Falando em Agile</a> organized by Caelum. Both will happen in October while I am at <a href="http://www.oopsla.org/">OOPSLA 2008</a> so I won't be there but I expect them to be quite interesting.<br /><br />And get ready for next year, our goal is to have at least one international speaker.Hugo Corbuccihttp://www.blogger.com/profile/08306316717477317361noreply@blogger.com0tag:blogger.com,1999:blog-1597571711823966454.post-887991613401809732008-10-04T21:09:00.002-03:002008-10-04T21:22:14.338-03:00Archimedes' screenshotsHello everyone,<br />I've just updated the <a href="http://www.archimedes.org.br">archimedes web site</a> to include user registration. Now, all the content is dynamical. Both the front page as well as the screenshots are dynamically added by a special user (me). I also implemented a release page that will soon become a download page.<br />The great advantage in all this is not really to the users but mostly to myself. It allows me to easily and quickly update stuff about Archimedes. Once the download page is up, I should probably give it a rest for some time. Work a bit more on the software itself.<br /><br />I hope to improve this system to plug it to the repository (http://svn.archimedes.org.br/public/) and have releases and a few more stuff updated automatically. It would be fantastic. If I get it to work, I might even open this to more people to create their projects in another website. Archimedes' site will become a plug in forge in that case. I'm investing a lot into this quick feedback tool in order free more time to code later on. Let's hope it works.<br /><br />During my development I found a small bug in <a href="http://svn.techno-weenie.net/projects/plugins/attachment_fu/">attachment_fu</a>. If you do not specify an image processor to your image model and you use ImageScience, gif thumbnails' path get messed up. I've sent the patch to <a href="http://www.techno-weenie.net/">Rick Olson</a> but if you want it, it is simple. Open up attachment_fu.rb, go to line 85 and 86 and change them from:<br /><span style="font-family: courier new;">attachment_options[:processor] = "#{processors.first}Processor"</span><br /><span style="font-family: courier new;"> processor_mod = Technoweenie::AttachmentFu::</span><div dir="ltr"><wbr style="font-family: courier new;"><span style="font-family: courier new;">Processors.const_get(</span><wbr style="font-family: courier new;"><span style="font-family: courier new;">attachment_options[:processor]</span><wbr style="font-family: courier new;"><span style="font-family: courier new;">)</span><br />to:<br /><span style="font-family: courier new;">attachment_options[:processor] = processors.first</span><br /><span style="font-family: courier new;">processor_mod = Technoweenie::AttachmentFu::</span><wbr style="font-family: courier new;"><span style="font-family: courier new;">Processors.const_get("#{</span><wbr style="font-family: courier new;"><span style="font-family: courier new;">attachment_options[:processor]</span><wbr style="font-family: courier new;"><span style="font-family: courier new;">.to_s.classify}Processor")</span><br /><br />Restart your server and this should do the trick.<br /><br />Well, that's it for now.<br />Bye bye<br /> </div>Hugo Corbuccihttp://www.blogger.com/profile/08306316717477317361noreply@blogger.com2tag:blogger.com,1999:blog-1597571711823966454.post-47923527653431906702008-09-29T08:43:00.002-03:002008-09-29T08:54:28.867-03:00Archimedes' site becoming a forgeHello there,<br />I've been working on archimedes.org.br website a little lately. It just happens that I have been working on it to make it a forge instead of a simple project website.<br />The idea is that I can host any plugin development to archimedes on the site providing a repository and a nice bug tracking system and system presentation. It is also open source and is already available at <a href="http://svn.archimedes.org.br/public/br.org.archimedes.www/">http://svn.archimedes.org.br/public/br.org.archimedes.www/</a>. It works using Ruby on Rails 2.0.2 (I know I'm a bit outdated) and so far only has features for archimedes.<br /><br />So far the system is pretty simple. I have projects, each project has versions.<br />There are users and users can have a ProjectMembership relationship with a project (and vice-versa).<br />My next step is to create a screenshot posting system that relates them to versions. This way screenshots can be dated and related to versions and operating system (still to be created). I hope I managed to improve this part until next sunday and then release it to the site itself.<br /><br />I am trying to get a repository dump of current archimedes' subversion repository because I want to migrate it to the new address. However, it looks like people are too busy to run a command line to help me at the incubadora. I will insist and, luckily, we will soon have a new home with all the commit logs and past under archimedes' address. It will give me more control over what happens and how to track it.<br /><br />That's it for now. Work calls. Bye bye!Hugo Corbuccihttp://www.blogger.com/profile/08306316717477317361noreply@blogger.com0tag:blogger.com,1999:blog-1597571711823966454.post-79498251244705287332008-09-23T11:22:00.002-03:002008-09-23T11:28:14.145-03:00Archimedes' marketing first stepHello,<br />I've worked a little on Archimedes' first marketing steps.<br />I've changed the DNS pointers to my dreamhost account and set up a first version of the website. It currently only features the main page and I am working on the Screenshot page. Screenshots will be related to an operating system and a version. This way, people will be able to see screenshots and know how their Archimedes should look like in their computer.<br />I am working on the model of this and hsould restrict access to a few stuff on that. I hope I can finish this by this weekend. This might also produce the Download page since I will need to have versions which will be linked to the files of those versions.<br /><br />I also payed for another 5 years of archimedes.org.br and arquimedes.org.br so the website is ensure for some time.<br /><br />Finally, I am trying to reply bug reports and solve them as quickly as I can. I am focusing on Bug Reports and Support Requests leaving Features aside until I can have the current version working decently. Please send me feedbacks about any of those.<br /><br />See you later.Hugo Corbuccihttp://www.blogger.com/profile/08306316717477317361noreply@blogger.com0tag:blogger.com,1999:blog-1597571711823966454.post-76687672550975246162008-09-23T10:35:00.003-03:002008-09-23T11:19:53.550-03:00PyCon Brazil summaryHello,<br />I came back from PyCon Brazil on Sunday morning. It was a very pleasant experience although I was there only for half of the conference. There were three main things that are worth writing about.<br /><br />The first one was a nice chat I had with <a href="http://www.isnomore.net/">rbp</a> and <a href="http://www.artima.com/weblogs/viewpost.jsp?thread=238994">Bruce Eckel</a> about the Coding Dojo. To start, I explained a little bit about the Coding Dojo dynamics and the practices used and rbp helped me with some details. Once Bruce got the idea, we talked about collaboration between Dojo (specifically about São Paulo's Dojo and Paris' one) and the tools we needed for that. It soon become a crazy MMOG (Massive Multiplayer Online Game) where people from all over the world could join and choose a theme where there would be rooms hosting coding dojos. It would be running 24 hours per day since there is always a dozen programmers awake willing to code some more. We all agreed that this would never replace the physical coding dojo meetings but it could serve as a motivator to join them. We discussed what are the tools lacking for that and how viable it would be to build them and have them work. Was a pretty cool idea. I would gladly start that if I wasn't already so late with all the other projects ;)<br /><br />The next noticeable event was the Coding Rumor (or Ultra-Dojo) session that we hosted. It was very instructive although it obviously didn't work out very well. The main problem was that participants were not TDD programmers which ment that their approach to solve the problems did not followed the baby steps' principle. The result was a code that seemed to work but was very hard to understand and was not very well test covered.<br />I could learn from the experience that this exercice should only be done with people that are fluent with TDD and the regular Coding Dojo should be used to take people to that step. Another interesting thing was that the retired position was more harm then good. It quickly became a continuation of the previous round were the retired ordered the pilot each step he should make. We, therefore, decided that this position should be eliminated since the pilot always has the pointer to its retired. If needed, he can call him for help but he should be away from the current pair.<br /><br />Finally, the Coding Dojo session was pretty cool. We had around 20 attendees and most of them had never heard of Coding Dojo. If I remember correctly, about three persons sometimes wrote test firsts, about eight sometimes wrote tests. So mainly, people were really NOT experienced TDDers. The good thing is that this was not a major problem. I presented the ideas using <a href="http://www.agilbits.com.br/material/DojoIntroPyconBrasil2008.pdf">this slides</a> (english version <a href="http://www.agilbits.com.br/material/DojoIntroPyconBrasil2008-en.pdf">here</a>) and then we started to solve the <a href="http://codingdojo.org/cgi-bin/wiki.pl?KataBankOCR">Bank OCR problem</a> from <a href="http://codingdojo.org/">codingdojo.org</a>. I followed Kiko's suggestion to present the problem slowly (giving smaller goals at the beginning and growing them as they were reached) and let them start coding. It was interesting to see how hard it was for them to adapt to other people's ideas. Every co-pilot that arrived had a new idea and wanted to erase the previous one. I let this happen for a couple rounds then stopped it and made them follow the idea they were on by refactoring slowly towards the suggested solution. They managed to solve each digit using a dictionary this way and had some weird suggestion that coupled the implementation and the tests together (using the dictionary on tests or a copy of it) which they abandoned after a few arguments. After that, they went to parse several digits and had some problems to write the split string function. I suggested writing a test and they did and passed it. They were convinced it was going to work so they asked for another two rounds to finish the problem and accepted staying 15 minutes longer after the time for it. Unfortunetaly, the test was not complete and their implementation crashed. Took them a few mins to understand that they were lacking a test but they did and once it was written they accepted to stop.<br />The retrospective was pretty cool and we noticed that most problems pointed were heavily related to the lack of experience of the group to those programming practices although they valued a lot all the ideas they had seen. I guess it was pretty much a success and I hope people will start more Coding Dojos around Brazil. My homework from the session was to provide a video showing a Coding Dojo session to do the marketing to other people. I already talked to people at São Paulo's Coding Dojo and we are going to record our next sessions to try have this video ready soon.<br /><br />I guess that is all for now. Bye bye people.Hugo Corbuccihttp://www.blogger.com/profile/08306316717477317361noreply@blogger.com4