I was waiting for the legal advisor of TechTalk to review the five lines I wrote about my visit at their office the week before, which caused some delay in my blogging queue, but now I am back on track and will continue with week number three of my tour. I started the week with going to the country-side of Lower Austria. While driving I reflected about my tour (and I already published my thoughts here). Markus Schinerl had invited me to stay at his house for three days. Markus runs a small company called sdguide.org which is specialized in calculating metrics like the carbon footprint for factories in the pulp and paper industry. Pulp and paper is a very competitive industry and customers like governments demand the highest environment-conserving certificates from their paper providers. Sdguide's office was located in an old house and due to old age and structural damage it was under construction and looked terrible, see the image on the right side. Some windows were broken and we worked on a raw, wooden construction resembling a table. However we had a powerful computer, two keyboards and two huge screens - no problem there ;-)
Spreadsheet Monstrosities
Markus used a gigantic spreadsheet to enter all parameters needed for such a calculation. It contained roughly 200 input parameters and 500 metrics for up to 50 product parts resulting in huge files with thousand of lines. Obviously Excel was reaching its limits and he needed something more powerful. We spent the first day discussing the domain of carbon footprint and created a small diagram defining the core elements of his calculations. Although we did not write any code it was a productive day because I helped Markus to reflect on his needs and he explained the requirement to me at the same time. We came to the shared conclusion that he needed a real database, but one that he might be able to develop himself, so we ended with Visual Basic (for Applications aka VBA) and MS Access. Although I did not fancy VBA it was the best choice for his needs and he liked the idea that he would be able to use parts of our VBA code in his spreadsheets as well.
Markus had used VBA some years ago and I had never worked with it before. It took us half of a day googling and reading StackOverflow until we got fluent and then we flew. VBA does not offer much and I missed a lot like unit testing, collection classes, closures and much more, still we made good progress. At the end of the second day, actually the very end of the day - it was 10pm, we had built full end-to-end functionality. Of course it was not finished and only calculated one simple formula of one metric for one product part without considering scenarios, different years or different customers. Still it showed the way. I had aimed for that because we needed to know if the chosen design would work. It looked good. During the third day we added more features Markus wanted to investigate, we even created an infix math parser to evaluate arbitrary formulas. It was great and I learned a lot.
Being Brutal
Back in Vienna I helped a small team of developers to improve their refactoring skills. The developers liked practice and I chose Adrian Bolboaca's Brutal Refactoring Game. I had participated in Adrian's session during XP2013 earlier this year and had liked it a lot. It is a programming challenge focusing on refactoring. The brutal part is that each code smell needs to be refactored right now, regardless how small it is. This makes an excellent exercise to train developers in spotting code smells and refactoring them. Adrian lists 17 code smells as the base of the game and I asked the team to prepare short presentations about each of them. At the beginning of the session the developers presented the material to the audience. I just love when trainees teach themselves ;-) During the sessions I collected all the smells I had flagged. Half of them was about naming, i.e. "name not from domain" and "name not revealing intent" which did not surprise me because naming is a difficult problem. Further 30% were "Primitive Obsession" and "lack of tests", common problems in most code bases. One participant was disappointed that he did not hit each of the 17 smells at some point during the game - maybe I will add some game like achievements for completionists like him.
Even for a small group it was demanding to watch out for the smallest code smell in several evolving code bases at the same time. I noticed that pairs kept hitting the same smells again and again. Besides naming, which all participants had to deal with, one pair was "obsessed with primitives" several times, whereas another team had trouble writing tests to cover their design ideas. A fast typing pair, two developers who knew their IDEs well, created a lot of code, but as soon as I found a smell they were unable to remove it by refactoring and had to delete the new code and start over. Although I was as brutal as possible and challenged the participants a lot, I got positive feedback after the exercise and all participants learned something.
The Java User Groups of Austria
For the rest of the week I went "on tour" with the Java Klassentreffen 2013. The Klassentreffen is a series of events organized by the Austrian Java training company Ciit and sponsored by Oracle. It is a mixture of sales pitches and technical presentations, covering various aspects of Java. Technically the Klassentreffen did not meet my requirements for the pair programming tour, but the organizers had invited me to speak and food was provided. Together with Martin Ahrer, the founder of the eJUG Austria, I introduced the audience to Java and Java related user groups in Austria. I started my talk with the reasons to attend user groups, then covered the core groups of Java, Eclipse, Android and Scala and finished the presentation with Open Source, Software Craftsmanship and upcoming Code Retreats. (For details and links please open the slides.) Later the leaders of several groups told me about new registrations, so I guess my presentation was a full success.
27 September 2013
CodeCopTour Week 2
Culture Shock
My second week's journey brought me to the highest towers of Vienna (see picture on the right). After previous week's startups this felt different. Paul Rohorzka had invited me to join him for two days. I had not known Paul before but had seen his name on the manifesto. Later when I met him in person during a Code Retreat I told him about my tour and he immediately agreed to pair with me. Working for a regular company TechTalk he had to get permission for my visit which took some time to figure out but finally he managed.
In the morning Paul surprised me with a list of several things he wanted to work on. On his current assignment he worked alone and lacked potential reviewers and therefore wanted several pieces of his code discussed. He had prepared his expectations, work packages and a list of verification "milestones" for these two days. After previous' week marathon coding sessions I felt like using Pomodoros and his work packages were sized small enough to fit into Pomodoros which we kept doing both days.
On the first day we worked on improving the readability of his specs. He used SpecFlow, a BDD testing tool for .NET, which worked just fine. I am generally disappointed by .NET tooling, but I was positively surprised how nice SpecFlow worked, just like you would expect it to work. Although we did not finish the work on the specs, Paul wanted to work on something else the second day, to get as much coverage of his work as possible. We dived into test infrastructure and reworked the part for creating test data. Its core class really needed some refactoring and we spent the entire day cleaning it up and making it ready for new features Paul knew he would have to add soon.
Paul is a true craftsman. I thought that I was a structured worker, but he was much more structured than I, which was nice to witness - there is always room for improvement ;-). Although I had never worked with C# before we had a shared understanding and were productive after the first hour. I enjoyed working with him and had a great time. Thank you Paul.
In the middle of the week I moderated the September Coding Dojo of the Scala User Group Vienna. (A Coding Dojo is a meeting where a bunch of coders get together and work on a small programming challenge to improve their skills. You can find more information about Coding Dojo in Emily's excellent Coding Dojo Handbook.) It was their eight dojo and I wanted to try something more advanced than basic code katas. I chose the TDD as if you meant it exercise by Keith Braithwaite. This was a difficult exercise and it was difficult on purpose, but the participants did well, much better than I did my first time during GeeCON 2012. It was my first time facilitating and their first time working through this exercise, and all of us learned a lot.
Yak Shaving
The remainder of the week Florian Pirchner hosted me in the office of his company Lunifera. I knew Florian since several years as organized the Eclipse DemoCamp in Vienna together. Lunifera was a development shop specialized in OSGi technologies and its "office" was still located in the living room of his flat which made a comfortable place to work and we had a lot of fun. But the work - the work was terrible and we spent almost three days Yak Shaving.
When I arrived at Lunifera, Florian showed me his current pet project, a radio controlled air swimmer, a flying shark, using BeagleBone, Arduino, many cables and - of course - OSGi technology. He prepared the project for his upcoming talk at EclipseCon Europe and needed some third-party code deployed to Eclipse Virgo, an OSGi compliant server. And it just did not work. After reading the documentation several times, we started from scratch, took baby steps and reproduced the smallest examples from the documentation. Based on these working Virgo examples, we moved forward to implement the code he needed, a m2m server based on Apache ActiveMQ. Besides some integration tests, we did not write a single line of Java, but many lines of poms, manifests, Spring and other XML configurations. I hate infrastructure work. Finally we got it to work and Florian was thankful for my help on this task, I even got a new nick-name "Config-Cop" ;-)
My second week's journey brought me to the highest towers of Vienna (see picture on the right). After previous week's startups this felt different. Paul Rohorzka had invited me to join him for two days. I had not known Paul before but had seen his name on the manifesto. Later when I met him in person during a Code Retreat I told him about my tour and he immediately agreed to pair with me. Working for a regular company TechTalk he had to get permission for my visit which took some time to figure out but finally he managed.
In the morning Paul surprised me with a list of several things he wanted to work on. On his current assignment he worked alone and lacked potential reviewers and therefore wanted several pieces of his code discussed. He had prepared his expectations, work packages and a list of verification "milestones" for these two days. After previous' week marathon coding sessions I felt like using Pomodoros and his work packages were sized small enough to fit into Pomodoros which we kept doing both days.
On the first day we worked on improving the readability of his specs. He used SpecFlow, a BDD testing tool for .NET, which worked just fine. I am generally disappointed by .NET tooling, but I was positively surprised how nice SpecFlow worked, just like you would expect it to work. Although we did not finish the work on the specs, Paul wanted to work on something else the second day, to get as much coverage of his work as possible. We dived into test infrastructure and reworked the part for creating test data. Its core class really needed some refactoring and we spent the entire day cleaning it up and making it ready for new features Paul knew he would have to add soon.
Paul is a true craftsman. I thought that I was a structured worker, but he was much more structured than I, which was nice to witness - there is always room for improvement ;-). Although I had never worked with C# before we had a shared understanding and were productive after the first hour. I enjoyed working with him and had a great time. Thank you Paul.
In the middle of the week I moderated the September Coding Dojo of the Scala User Group Vienna. (A Coding Dojo is a meeting where a bunch of coders get together and work on a small programming challenge to improve their skills. You can find more information about Coding Dojo in Emily's excellent Coding Dojo Handbook.) It was their eight dojo and I wanted to try something more advanced than basic code katas. I chose the TDD as if you meant it exercise by Keith Braithwaite. This was a difficult exercise and it was difficult on purpose, but the participants did well, much better than I did my first time during GeeCON 2012. It was my first time facilitating and their first time working through this exercise, and all of us learned a lot.
Yak Shaving
The remainder of the week Florian Pirchner hosted me in the office of his company Lunifera. I knew Florian since several years as organized the Eclipse DemoCamp in Vienna together. Lunifera was a development shop specialized in OSGi technologies and its "office" was still located in the living room of his flat which made a comfortable place to work and we had a lot of fun. But the work - the work was terrible and we spent almost three days Yak Shaving.
When I arrived at Lunifera, Florian showed me his current pet project, a radio controlled air swimmer, a flying shark, using BeagleBone, Arduino, many cables and - of course - OSGi technology. He prepared the project for his upcoming talk at EclipseCon Europe and needed some third-party code deployed to Eclipse Virgo, an OSGi compliant server. And it just did not work. After reading the documentation several times, we started from scratch, took baby steps and reproduced the smallest examples from the documentation. Based on these working Virgo examples, we moved forward to implement the code he needed, a m2m server based on Apache ActiveMQ. Besides some integration tests, we did not write a single line of Java, but many lines of poms, manifests, Spring and other XML configurations. I hate infrastructure work. Finally we got it to work and Florian was thankful for my help on this task, I even got a new nick-name "Config-Cop" ;-)
21 September 2013
Journeyman Tour is hard work
The post about my second week is ready since some days but I am waiting for it to be reviewed by the company I visited. In the meantime let me tell you about some other aspect of my Journeyman tour.
At the beginning of the third week I drove to the country-side to pair with an old friend. While driving, I used the time to reflect about my tour. The quiet activity of driving seemed to support reflection. At some point I stopped to take notes so I would not forget, something that Corey called Road Thoughts. Corey recorded several of them during his tour as he drove around all the time.
Preparation takes time
A Journeyman tour might be seen as a funny or exciting undertaking, which it certainly is, but most of all, it is hard work. It started with the preparations, which were time consuming. Over three months I spent considerable effort in contacting people, promoting my tour, and finally finding individuals who would host me. I regularly spent two hours on emails, usually after regular work in the evening. Because I wanted to do my tour in Vienna, and because Software Craftsmanship is not widely known there, I needed to explain the tour, my motivation and potential benefits to future hosts and their managers again and again. (I will discuss how to sell such a Pair Programming Tour to management in a later post.) I roughly spent a man-month (160 hours) on preparations and discussions to find 20 to 25 hosts who would host me for a total of three months.
I never worked that hard
Facing a new project every three days is exhausting. There is no time to get used to it and obviously I want to be productive as soon as possible. New projects with new technologies in new domains are not a problem by themselves, but the cognitive load is extreme. There are many things I learn every hour and I constantly need to do things I never did before. I assume digesting this new knowledge comes "with a cost" - I am very tired in the evenings. I work with my hosts from morning to evening, usually seven to eight hours and after work we might add a retrospective or discuss some geek issues while drinking beer. Surely I overdid my tour by attending as many user group meetings as possible to promote the idea of Pair Programming Tour.
Pairing is intense
I try to pair 100% with my host. Even when Nik had to write a technical mail regarding Dart build issues, or when Florian had to create a cash flow spreadsheet for an upcoming project, we worked together. Pair programming is more demanding than regular work. There are no distractions, no mails or Twitter, because we are working on something. We keep each other focused all the time (and sometimes skip breaks or forget to drink which is a bad thing). This work is intense all day, five days a week.
Personal Pressure
The uncertainty of a new host, paired with possible expectations they might have, make me uneasy. What is my host really expecting? Will I fail? Will I look stupid? I know that there is no failing, still the thoughts of doubt are here. I feel the need to get something done, to deliver some value. This is my personal commitment for my host. On some occasions it caused me to take short-cuts during pair development, which I had never taken before and should not have taken at all.
Sharing needs time as well
Finally I want to blog about my tour. Summarizing what happened during the week is important to reflect on the things I learned. I found many things I need to share with future Journeyman, observations about our craft and other fascinating topics. Also people keep asking me about my tour. I initially planned to write blog posts twice a week, one diary and one about some discovery I made. I am a slow writer and I am two posts behind schedule already. But I promised Corey Haines himself that I would write about my tour. He is watching me, and these posts will be written ;-)
At the beginning of the third week I drove to the country-side to pair with an old friend. While driving, I used the time to reflect about my tour. The quiet activity of driving seemed to support reflection. At some point I stopped to take notes so I would not forget, something that Corey called Road Thoughts. Corey recorded several of them during his tour as he drove around all the time.
Preparation takes time
A Journeyman tour might be seen as a funny or exciting undertaking, which it certainly is, but most of all, it is hard work. It started with the preparations, which were time consuming. Over three months I spent considerable effort in contacting people, promoting my tour, and finally finding individuals who would host me. I regularly spent two hours on emails, usually after regular work in the evening. Because I wanted to do my tour in Vienna, and because Software Craftsmanship is not widely known there, I needed to explain the tour, my motivation and potential benefits to future hosts and their managers again and again. (I will discuss how to sell such a Pair Programming Tour to management in a later post.) I roughly spent a man-month (160 hours) on preparations and discussions to find 20 to 25 hosts who would host me for a total of three months.
I never worked that hard
Facing a new project every three days is exhausting. There is no time to get used to it and obviously I want to be productive as soon as possible. New projects with new technologies in new domains are not a problem by themselves, but the cognitive load is extreme. There are many things I learn every hour and I constantly need to do things I never did before. I assume digesting this new knowledge comes "with a cost" - I am very tired in the evenings. I work with my hosts from morning to evening, usually seven to eight hours and after work we might add a retrospective or discuss some geek issues while drinking beer. Surely I overdid my tour by attending as many user group meetings as possible to promote the idea of Pair Programming Tour.
Pairing is intense
I try to pair 100% with my host. Even when Nik had to write a technical mail regarding Dart build issues, or when Florian had to create a cash flow spreadsheet for an upcoming project, we worked together. Pair programming is more demanding than regular work. There are no distractions, no mails or Twitter, because we are working on something. We keep each other focused all the time (and sometimes skip breaks or forget to drink which is a bad thing). This work is intense all day, five days a week.
Personal Pressure
The uncertainty of a new host, paired with possible expectations they might have, make me uneasy. What is my host really expecting? Will I fail? Will I look stupid? I know that there is no failing, still the thoughts of doubt are here. I feel the need to get something done, to deliver some value. This is my personal commitment for my host. On some occasions it caused me to take short-cuts during pair development, which I had never taken before and should not have taken at all.
Sharing needs time as well
Finally I want to blog about my tour. Summarizing what happened during the week is important to reflect on the things I learned. I found many things I need to share with future Journeyman, observations about our craft and other fascinating topics. Also people keep asking me about my tour. I initially planned to write blog posts twice a week, one diary and one about some discovery I made. I am a slow writer and I am two posts behind schedule already. But I promised Corey Haines himself that I would write about my tour. He is watching me, and these posts will be written ;-)
14 September 2013
Journeyman Findings 1
Here are some notes I took during the first week of my Pair Programming Tour.
Discuss the expectations with your host up front.
At the end of each visit I do a short retrospective with my host. After pairing with Nik Graf for two days, we did such a retrospective and I found that he had different expectations for the past two days. He had paired with other people before, usually technical experts in one or the other area of the Blossom technology stack. He and his pair would hack away deep inside the bowels of Blossom code and get things done. When I joined him, he had to fix a potential security problem and we worked on some Google App Engine specific part of the application. I learned a lot but was not able to contribute much on this level of detail. I helped him with changes and offered general comments and advice on build, testing and deployment - whatever we touched during our work. That was not what he expected, nevertheless he assured me that my contribution was welcome, just on a higher level, "in a way how he had not looked at his application since a long time". We should have discussed his expectations at the morning of my arrival.
An initial design might block your options.
When I paired with Raphael last week, we discussed his needs and came up with a small drawing depicting a possible design. Coding went well for some time and we followed our design that I jokingly called our BDUF. After building several classes, Raphael noticed that he needed a feature that he had not thought of before. Instead of embracing the change in our design, I somehow did not like the idea and talked him out of it. In the evening during our daily retrospective we discussed what had happened. The needed change would have destroyed the initial design but I liked it and was almost proud of it. Subconsciously I had rejected the idea of a change that would invalidate my plan. I did not know that it was because of the design up front until we talked about it.
Bring keyboards for all languages used in your area.
Even when pairing on a small laptop an additional keyboard and mouse allow to change between driver and navigator roles more easily and so I brought my own keyboard with me right from the start. In Austria we use German keyboard layout but some developers use English laptops or just like to use English keyboards. Raphael used an English keyboard and showed me where to switch layouts, so I would be able to work with my German keyboard as well. Switching keyboard language took time and we forgot about it often resulting in both of us typing wrong keys. I knew the English layout and we decided to stay with it. Then I was struggling to find the proper keys for special characters like {}. On the next day I brought an English keyboard which resolved all my typing issues.
This is a positive experience!
When I explained my tour to some fellow coders, one asked me if I would create a list of worst code I have seen. I answered him that this tour is a positive experience. I have worked for big companies and I already know how bad code can look like. I assume that in the last 14 years I created more bad than clean code myself. I will not collect any findings because I am not interested how bad your code is. I am interested how you work and how you try to improve your code. Hosting a journeyman for a pairing session is a sign that you want to grow and I can show you how to fix that legacy code.
Discuss the expectations with your host up front.
At the end of each visit I do a short retrospective with my host. After pairing with Nik Graf for two days, we did such a retrospective and I found that he had different expectations for the past two days. He had paired with other people before, usually technical experts in one or the other area of the Blossom technology stack. He and his pair would hack away deep inside the bowels of Blossom code and get things done. When I joined him, he had to fix a potential security problem and we worked on some Google App Engine specific part of the application. I learned a lot but was not able to contribute much on this level of detail. I helped him with changes and offered general comments and advice on build, testing and deployment - whatever we touched during our work. That was not what he expected, nevertheless he assured me that my contribution was welcome, just on a higher level, "in a way how he had not looked at his application since a long time". We should have discussed his expectations at the morning of my arrival.
An initial design might block your options.
When I paired with Raphael last week, we discussed his needs and came up with a small drawing depicting a possible design. Coding went well for some time and we followed our design that I jokingly called our BDUF. After building several classes, Raphael noticed that he needed a feature that he had not thought of before. Instead of embracing the change in our design, I somehow did not like the idea and talked him out of it. In the evening during our daily retrospective we discussed what had happened. The needed change would have destroyed the initial design but I liked it and was almost proud of it. Subconsciously I had rejected the idea of a change that would invalidate my plan. I did not know that it was because of the design up front until we talked about it.
Bring keyboards for all languages used in your area.
Even when pairing on a small laptop an additional keyboard and mouse allow to change between driver and navigator roles more easily and so I brought my own keyboard with me right from the start. In Austria we use German keyboard layout but some developers use English laptops or just like to use English keyboards. Raphael used an English keyboard and showed me where to switch layouts, so I would be able to work with my German keyboard as well. Switching keyboard language took time and we forgot about it often resulting in both of us typing wrong keys. I knew the English layout and we decided to stay with it. Then I was struggling to find the proper keys for special characters like {}. On the next day I brought an English keyboard which resolved all my typing issues.
This is a positive experience!
When I explained my tour to some fellow coders, one asked me if I would create a list of worst code I have seen. I answered him that this tour is a positive experience. I have worked for big companies and I already know how bad code can look like. I assume that in the last 14 years I created more bad than clean code myself. I will not collect any findings because I am not interested how bad your code is. I am interested how you work and how you try to improve your code. Hosting a journeyman for a pairing session is a sign that you want to grow and I can show you how to fix that legacy code.
Labels:
CodeCopTour,
journeyman tour,
keyboard,
software craftsmanship
11 September 2013
CodeCopTour Week 1
Finally my Journeyman tour started last week. My first host was Raphael Stary from letsplay.io, a fresh startup creating the next level of social games. The "next level of social games" sounded like a mixture of FarmVille and World of Warcraft ;-) - playing with your friends using your mobile phone - hot stuff! Raphael was very kind and it was a great experience. After some initial chitchat he revealed his plans for me: to use my Java skills for creating the server side component of his newest game. We spent three days pairing intensively and I was happy with our result, an almost complete back-end including integration tests. All the discussions about the domain and the technical details of browser based games sparked the idea to create my own game. I used to code little games many years ago and had forgotten the joy of doing so. Maybe I will create something small after my tour when things have settled down again.
Being in Sektor5, a relaxed local coworking space, I took the opportunity to visit another startup, Blossom, a lean Kanban board. Blossom was founded a few years ago, and after winning some funding they mainly operate in the San Francisco area now. Blossom has customers from companies like Twitter or Google, an impressive feat for a Viennese startup. Blossom CTO Nik Graf paired with me for two days. He showed me their impressive technology stack and I saw many technologies I had never seen before, probably too much to digest in two days. I enjoyed the atmosphere of a real technology startup. Rock on guys! (I confess I am a Blossom fan boy now, just like half of the coworking space ;-)
During my tour I plan to visit as many user group meetings as possible. The Vienna Ruby Group meets in the same coworking space and I squeezed myself into the agenda and introduced the Ruby enthusiasts of Vienna to the idea of Software Craftsmanship and the Journeyman Tour. After the presentations we had a great discussion about craftsmanship, pair programming, and quality in general. I liked talking to passionate developers and will attend future meetings as well.
Last week was a blast. I learned a lot both about our craft and myself. My journal is full with notes and findings, which I will share in shorter posts in the next days.
Being in Sektor5, a relaxed local coworking space, I took the opportunity to visit another startup, Blossom, a lean Kanban board. Blossom was founded a few years ago, and after winning some funding they mainly operate in the San Francisco area now. Blossom has customers from companies like Twitter or Google, an impressive feat for a Viennese startup. Blossom CTO Nik Graf paired with me for two days. He showed me their impressive technology stack and I saw many technologies I had never seen before, probably too much to digest in two days. I enjoyed the atmosphere of a real technology startup. Rock on guys! (I confess I am a Blossom fan boy now, just like half of the coworking space ;-)
During my tour I plan to visit as many user group meetings as possible. The Vienna Ruby Group meets in the same coworking space and I squeezed myself into the agenda and introduced the Ruby enthusiasts of Vienna to the idea of Software Craftsmanship and the Journeyman Tour. After the presentations we had a great discussion about craftsmanship, pair programming, and quality in general. I liked talking to passionate developers and will attend future meetings as well.
Last week was a blast. I learned a lot both about our craft and myself. My journal is full with notes and findings, which I will share in shorter posts in the next days.
Subscribe to:
Posts (Atom)