So far, I think I have undervalued the importance of some practices when it comes to working in a large-scale development shop with lots of teams. One of the major problems with software development in the large is that we as an industry of software developers are terrible. We have bad development practices in place, and it’s strikingly easy to hide your bad software development skills in larger corporations. I also think that the Craftsmanship movement could come up just because we have badly educated software developers since decades.
Back in 2009 I attended my first coding dojo. It did not take long for me to realize that it was fun, and all the programmers in that setting learned a lot. Ever since I was convinced about what some call Deliberate Practice. It’s a practical exercise to help you learn a deeper understanding of a skill – most often accompanied with a mentor or coach that provides you feedback. Let’s take a look into various formats that are suited for testers.
Recently I restarted the Wandering Book. The Wandering Book is a tiny book passed on from Craftsman to Craftsman, fromCmmunity to Community intended to collect the Zeitgeist of Software Craftsmanship. I deliberately decided to start passing this to the German Softwerkskammer user grups. The idea is to collect the different notions, sort of a guest book of all the local events happening all over Germany.
Since the first book seems lost, I decided to put a disclaimer in it at the beginning. Here is the initial entry I made.
Since it was shortly before Christmas, I put a wish on twitter last week:
Anyone who wants to give me a gift for x-mas, consider writing a programming language where “if (* == true)” results in a compiler error.
This inspired some ideas on the twittersphere, and I decided to bring this topic to the Hamburg Software Craftsmanship user group on last Tuesday. Here’s what we brainstormed together: The best programming language, ever.
I need to elaborate a bit on some of them.
Disclaimer: Don’t hate me, I’m just a messenger.
About two years ago I read Quality Software Management Volume 2 – First-order measurement from Jerry Weinberg. In it, he explains the differences between first-order and second-order measurements. The latter is a replacement measurement. Instead of measuring the thing, we measure something that we substitute for the thing that we are measuring. For example, measuring code coverage usually is a second-order measurement for test quality. It does not really measure the quality of the underlying tests, since you don’t know how many assertions lie behind the covered lines of code. In the same book, Weinberg also provides the concept of zero-order measurements for projects. A few months ago I was surprised that these seem to be focused on traditional projects, rather than agile ones. Since then I decided to come up with zero-order measurements for agile projects. So, here are some of the things I look for when entering a new client or company.
Last Saturday we had the first testautomation coderetreat in Munich. Woohoo! This was a kickstart for this new coderetreat format – besides the original one from Corey Haines, and the Legacy Coderetreat format from J.B. Rainsberger. Here is my report from the facilitator’s point of view and with some hints about what I am going to try at different other follow-up coderetreats.
If you have followed this blog long enough, then you might have crossed the Testautomation Coderetreat in Munich which we planned for June 2nd. I apologize for having to cancel the first meeting on such a short notice, but we found it unprofessional to stick to the date. Here is the reason we had to postpone this date:
While this might mean, that I will have to do lots of other duties in the next few weeks – well, at least my priorities will change a bit – we also planned in a replacement for the for the first testautomation coderetreat. The new date is now the 11th of August, again in Munich, Germany. Here is the link to the event on eventbrite, please sign up there: Testautomation Coderetreat Munich.
I remember a talk from Cory Foy back at XP 2010 in Trondheim, Norway. He referred to Corey Haines as the happiest guy in the world. Although he lost his job, he started to travel around in the world, from shop to shop, from company to company. He was able to learn so much in a single year that he continued his journeyman tour after that.
One thing that Corey Haines invented alongside is a Coderetreat. Up until the global day of Coderetreat last year on 3rd of December I didn’t know what a Coderetreat actually is. At the core are six sessions of 45 minutes each where you solve a problem in code. Then you delete your code, and do it again – maybe with a different pair partner.
Recently J.B. Rainsberger invented the idea of a Legacy Coderetreat. The idea there is similar to a Coderetreat, but have to deal with legacy code and improve it. I attended one Legacy Coderetreat in the mean time, and it was quite interesting to solve the problem of a big mess of code.
At some point back last year I got in touch with Corey Haines and Adam Goucher. We bounced some ideas back an forth, and I refined them later with Adrian Bolboaca to yield a Coderetreat for testautomation code. Now I am happy to announce the first Testautomation Coderetreat in Munich on June 2nd.
There are only 10 types of people in the world:
- Those who understand binary
- Those who don’t
How is your binary today?
If you want to become one of the former group, here is a coding kata for you. I derived this from a tester at a client who is currently pursuing his Computer Science degree. While he was asking for help on an exercise, we came up with the idea, that this exercise would be a pleasant coding kata.
Today I crossed my review comments for the Apprenticeship Patterns which I wrote back in 2009. I wrote a blog entry back at that time about My long road. Reflecting back over the past – maybe – 3 years, I noticed something I wanted to write about: alternatives to apprenticeships – most of them I came across at my current employer it-agile. I remember that we discussed the topic of apprenticeships a few weeks ago at the local software craftsmanship user group meeting in Münster. We found that the apprenticeship model does not fit well into Germany’s working model in the IT industry. So, we tried to come up with alternatives. Here are the ones I have seen implemented at different companies: Mentoring and Peer-Groups.