About Inhouse Coderetreat

What is a Coderetreat?
A Coderetreat is a full day hands-on coding workshop focused on the fundamentals of software development, software design and communication. During the day participants get several chances to try something completely different and have the opportunity to learn new ways of coding and testing, programming languages or IDE usage. A Coderetreat is a funny and exciting day for the people, sharing their thoughts on Test Driven Development (TDD), Simple Design and more.

The Role of the Facilitator
A Coderetreat is run by one or more moderators, called facilitators, who are an essential part of every Coderetreat. The facilitator guides the participants through the day and helps people to learn as much as possible. Different facilitators have different styles. (I like to explore these styles and travel to co-facilitate Coderetreats with other people, as I did for last year's GDCR.)

Hosting an Inhouse Coderetreat
In a business context Coderetreats are run inhouse and during working hours. Someone inside the company has to take over the role of the host, and care for the organisation, e.g. invite participants, find a proper room, etc. Usually this is done by a team lead or line manager, who is attending the event but not participating in coding. Lunch should be provided on-site for all participants. The lunch break is the perfect time for discussions and reflections on learning and participants should not wander off to get food on their own. Sometimes I allow lunch breaks up to 90 minutes to encourage more discussions.

Finding a Room
Finding a suitable room for a whole day can be challenging as large meeting rooms are scarce and contested resources in companies. The room must be suitable for people working on laptops in pairs and should be comfortable enough to allow for prolonged periods of working. Not all rooms are useful. University labs are not ideal because the room setup does not encourage pair working. Lecture rooms with benches are no good as they do not allow for comfortable coding. The facilitator should be able to walk behind the participants and movement between sessions should be free. Dividing participants into several rooms is possible if the rooms are located next to each other. The best setup is a single, large room with several tables, where each table allows one or more pairs working together. The best rooms are apart from the daily business, without disturbances, increasing the retreat character.

Further space is needed for the discussions and session retrospectives. Sometimes this is just an empty space in front of the room where people gather in a circle and talk, or it might be a different room - or even a light-flooded hallway. Sometimes a short walk to another room helps participants to detach from the previous exercise.

A Day of Learning and Practise
The goal of a Coderetreat is deliberate practise and learning. There is always something new to discover during such a day. Depending on the expectations and skills of the participants, the facilitator will choose suitable exercises that challenge them and push them outside their comfort zone. All exercises are based on TDD, Simple Design and Pair Programming. Even if participants are new to one or all these core practises, they will get a first experience using them. They will explore their first tests or might collaborate with more experienced developers and see how to drive their development with tests. It is a great way to start TDD. I have seen participants leave the event completely exhausted by all the new things they have learned.

For inhouse Coderetreats participation should be voluntarily. It is impossible to force people into learning. If someone does not want to attend, she can leave any time. During inhouse events I do explain more and push the participants less outside their comfort zone because they are still at work. Although it is difficult for me, I refrain from difficult or extreme constraints because I do not want to frustrate the participants. Some facilitators start an inhouse Coderetreat with a short presentation or discussion about the principles of TDD, Pair Programming and Object Orientation.

Kicking Off an Improvement Initiative
While an inhouse Coderetreat includes more teaching aspects than a public one, it is no training, there is no teacher and the participants strongly influence the day's agenda. Still it is a great way to get started with the spirit Software Craftsmanship, Continuous Improvement, Deliberate Practise, XP practises like Test Driven Development or Pair Programming and Agile Software Delivery in general. A major goal of an initial Coderetreat is to make people aware that there is more than training on the job and to spark the interest in topics like TDD or Clean Code. A Coderetreat is a great way to break the ice, because it is without any obligation for participants. I also make the whole day as much fun as possible, because fun is important for learning and I want my participants to look forward to future events. I strongly recommend running a Coderetreat to kick off any technical improvement initiative or coaching engagement.

The Facilitator's Perspective
A Coderetreat is also an opportunity for the facilitator and the host company to get to know each other, enabling further collaboration. Deliberate Practise events like Coderetreats or Coding Dojos cover only some aspects of technical improvement. Additional activities like lectures, focused programming workshops, team coaching, mentoring by Pair- or Mob Programming might be necessary. During a Coderetreat the facilitator sees how the participants approach problems, how they write code and how they communicate with one another. These fist impressions of the team's skills help to plan further learning activities.

Conclusion
Since I started working as independent trainer and coach in Vienna I have used the Coderetreat format extensively. Its open nature allows the participants to experience a way of practise and learning which are usually not known in enterprise environments. On the other hand it gives me a first idea of the overall skill level of the client's team and we get to know each other. I strongly recommend running a Coderetreat as kick off for any long term technical coaching engagement.

Thoughts on Mastery

During summer time I was on vacation in Tyrol which is an excellent place for hiking. A local magazine told a story about Josef Frauenschuh and his business of hand-crafted rakes. Josef is a true master craftsman: He is of old age, many years past official retirement. He creates large wooden rakes of highest quality using different kinds of wood for each part of the rake. His rakes are balanced and lightweight. He uses the best tools he can get, all of them are self-made and after 45 years he is still improving his tools and process. Obviously he does not accept any compromise. Once, when he needed more space to create the shafts, he simply made a hole in the wall of his workshop.

I liked the story a lot. It made me think about our craft and the concept of mastery.

I believe that one major aspect of mastery is age. It is not necessary by itself but rather is a side effect of the time needed to master a subject. Masters are aged because they have been practising their craft for 30 years or more and still try to improve. Following this definition it is obvious that there can not be many masters of software development, because our industry is still young. Only a few like Uncle Bob are working in the industry long enough, whereas most of us have less than ten years of experience. The so-called senior developers with five years of experience are just young journeyman, if at all.

Josef is working hard. Although he could retire any time, he is working five days a week because the demand for his rakes is high. He is a master and his rakes are masterpieces, but does he get rich? I do not think so. Following the story I assume he has to put considerable effort into each rake, and sometimes the wood splinters and he has to start over. Being curious I compared the prices and his rakes sell for around 70 Euro, whereas eBay has some for ten to 20 Euro, although no wooden ones. So yes, the masterpiece is up to five times more expensive than a regular one.

Still it seems that Josef is not earning five times more per hour than other workers. Could it be that master craftsmen are relatively underpaid because they put in extra work to create magnificent things? Maybe his rakes are expensive to compensate for the small number he is able to produce. That does not compare well to our industry. We (developers) are greedy. We expect a good salary matching our experience and competence. The more experience we have, the more money we want, which seems only fair. The never ending demand for IT professionals spoils us and salaries rise during the first years of junior developers' careers. At least they rise up to a certain point, which might be 15 years of experience, when we become "too senior" for most employers. But this is another story.

I do not know Josef Frauenschuh but I believe him to be a true master craftsman. Instead of bragging about his achievements, he is modest and admits that sometimes he even has to listen to outsiders to improve his rakes. He does not need titles of seniority, nor is he proclaiming himself to be a master. I guess he considers himself still a simple carpenter. He is a great example. Some of his modesty would suite us software people well, and I will start with myself.

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.

Corey's Pair Programming Tour

After my last rant on the missing quality in today's mainstream IT I got several mails from friends who had heard that I had quit my job (for the same reason). They asked me what I was up to now? The short answer is that I am planning a Pair Programming Tour (called Code Cop Tour). The long answer needs more explanation.

The Beginning
Like in every good story, let us start at the beginning - well maybe not at the very beginning, but let us start with Corey Haines. In 2008 Corey Haines, an US based programmer, lost his job and embarked on an unique, personal "Pair Programming Tour" around central US. He was travelling around, practising software development, pair-programming with people for room and board (room and food). InfoQ posted a summary about his first trip back in 2008, that I will in part repeat here: ... Corey Haines has embarked on a tour in the name of increasing our industry's emphasis on software as a craft. ... While he has dubbed the tour a "Pair Programming Tour", its ultimate intent is somewhat less about the practice of pair programming per se than it is about the ideas of what it takes for a software developer to really become good at what he or she does. ... Haines has posted video interviews revealing many of the unique insights he has gained about pairing, automated testing, and the evolution of a software craftsman while sharing the keyboard at the home-bases of Dave Chelimsky, Brian Marick, Uncle Bob Martin, and others.

Corey maintained a blog On Being A Journeyman Software Developer throughout his travels where he recorded his insights. While preparing for my own tour, I read it all, right from the first entry. Here is my summary:

Several Trips
Corey spent an entire year being a Journeyman Coder. A few others have done similar trips, but much shorter. These trips have been called "Pair Programming Tour", "Journeyman Tour", "Software Craftsman Road Trip", "Software Craftsmanship Walz" and so on. He split his journey into short tours of up to four weeks, using a conference or another event as leg for a trip.

For a certain trip he picked a region to explore, reached out to people that he knew in that region and talked to companies in the area, looking for places to allow him to visit. He knew a lot of people who worked from home, independents and remote workers, who he might visit. He prepared a list of places up front, with 50% already filled with people to pair or companies that would host him. For the remaining time he maintained a Pairing Calendar, that people interested in hosting him could look at.

Pair Programming
In general he spent between one and five days with people, usually two or three days, pair-programming on whatever they wanted to work on. He worked with people of widely varying experience and skill level on various projects. Due to the high density of well known individuals in his area he was also able to work with book authors, open source project leads and celebrities like Uncle Bob. He saw many aspects of software development, gained exposure to new software tools, learned new coding tricks and thus both actively trained others and got trained himself. (Pair Programming is next to many things a powerful technique for sharing knowledge.)

When visiting companies (I assume) he was just another member of the team and contributed as much as possible. Still he was an outsider with his own views and experiences, who most likely acted as agitator as well. (Obtiva's Jake Scruggs explained the role of agitator in his report about the 8th Light vs. Obtiva Craftsman Swap: The workers all believe the same, so they do not have a hard object to push up against. They got to sharpen their edges on me, and I got to sharpen my edges on them.)

Reflection during Travel
Between pairing sessions Corey drove around the country. He used the long road trips to think about what he had learned and reflect about conversations. He said himself that My head was so full of thoughts after the intense discussions with people; I just had to stop and record my very first "road thoughts." Maybe not by his planning, but this was an important part of a learning tour. To emphasize learning, we need to revisit the material studied before, reflect on it, sort it out.

Teaching
To Corey teaching was as important as learning. He updated his blog regularly, discussed new ideas or revisited old concepts. Next to recording his road thoughts he made several video interviews with people he had paired with. He talked at conferences and spoke at user groups on his way. Later he travelled around and organized Code Retreats in various places. He convinced people that software is a craft and explained the idea of Software Craftsmanship in general.

This is my understanding of the "classic" Journeyman Tour - and exactly this is what I will do. I am planning my tour since two months and in the next blog post I will describe my Code Cop Tour. Stay tuned ;-)

Where is the Quality?

I am professional Java developer since almost 14 years. I have been coding for education, fun and profit for 27 years and three months now. I bought my first book on how to program BASIC for the Commodore 64 in 1986, even before I got the computer itself. I have been enthusiastic about all this since then and never stopped pushing forward. But I am depressed. Maybe I get depressed easily, as once after a particular bad gig I had to take an antidepressant for more than a year. Fortunately no burn-out this time - I am just fed up. Time for a rant ;-)

The current state of the IT industry makes me unhappy. That is nothing new and maybe my last employer is a particular bad example, but I do not think so. I have been with some companies during my career and talked to developers working on different projects, and usually I hear the same story: Deadline first, crazy rush, get the shit out of the door, repeat. I am the Code Cop, I try to keep things together, clean them up, whip them into shape. But I am wasting my time. My work has no meaning. I am just one but "they" are legion. Recently I got really angry when being confronted with bad code. How do you dare to deliver such crap to my production code base. This is all a big joke.

Some developers have no idea about object orientation, encapsulation or how to design a class at all. The senior developers know their business and applications well, still some of them are unable to create a reasonable design or model classes with a single responsibility. This does not only apply to off-shoring, but to local teams as well. Managers and architects are talking about all aspects of the development cycle but the actual creation of the core asset, the executable code. Development of code is seen as a commodity, unimportant work, just fill in the gaps.

Dark Future
Last month I was invited to a small panel discussion. Together with a test automation expert and an user interface specialist, we were discussing with the audience about the future of software development. The opening question was for our advice for students of higher technical education. Where the testing and user interface people predict a bright future, I have a darker vision. I would not advise anybody who is passionate to start working in today's mainstream IT industry. Software is growing more and more complex and changing it takes longer and longer. At the same time the cost pressure increases. Current trends like Water-Scrum-Fall try to fix these problems with a process. The real issue is the bad quality of our code. We have accumulated a massive amount of technical debt. The same is true for testing. Yes, we plan for unit tests during development, but then need to finish the requirement first and skip the tests. In the end we get some UI test automation, delivered by an outsourced testing team. Hello software testing ice-cream cone.

Escape?
I get many mails from head hunters looking for Java developers. But their work is as broken as ours. I am sure, if they would just read one post of my blog they would not send me information about an open position for a junior developer who is supposed to add buttons to a web application. Some head hunters are even specialized in IT personnel but seem to be as (un-)skilled in their work as most of us. From my experience they just do not care, else they would not send me letters with a wrong name in the salutation. Anyway, all advertisements for job vacancies I have seen so far were flat and did not say anything about what to expect. I am not excited.

I believe that the Software Craftsmanship movement was born to address these issues. But Austria is a small country and I am not aware that there are companies like 8th Light around. Still I know of many passionate developers and would like to hear about companies, where all members of the development team are craftsmen. It will definitely be a small company, at least a small development team hiding somewhere. So please stop hiding and come outside, I am looking for you! (I really hope you exist ;-)

Required Reading: Clean Code

Here is an email that I wrote to my team earlier this year. The team members are able to deliver new features on time but do not care for code quality (at least not as much as I do ;-). This is going to change.

Raising the bar. ⁽¹⁾

Dear team,
as mentioned in the kick-off, we need to get into the right attitude for the upcoming refactoring effort. Many items on our code clean-up list are ongoing changes, e.g.

• use proper names for fields and methods
• clean up magic numbers
• split large classes
• add JavaDoc to core classes
• fix compiler warnings
• remove duplicated code
• remove dead code
• add JUnit tests

All of these changes are in fact rules how to produce code that is easy to read and maintain. All these rules are part of a coding style sometimes called "clean code".

The Pragmatic Programmers once wrote that you should read at least four technical books a year to stay sharp and relevant in our fast paced industry. Remember that the half-life of our technical knowledge in only 18 months. (Heinz Kabutz) So as first technical book to read in 2012 I highly recommend Clean Code by Bob Martin. It's a great book and has raised a new wave of code-consciousness. Read one of its reviews if you do not believe me.

Sooner or later you will have to read it, so why not start now? Go ahead, buy it, read it! Or at least browse it and see what is inside. We cannot afford to have any more cryptic variable names or huge classes.

Regards,
Code Cop

Lowering the bar.

Of course I did not attach the PDF of the book. That would have been illegal but it might lower the bar to get my colleagues into reading it. I know that not many of the team will read it. I would consider my email successful if one of two read the table of contents or browse a chapter.

⁽¹⁾ "Raising the bar" is the subtitle of the Software Craftsmanship Manifesto.

My Buddy Check List

Last DemoCamp a fellow craftsman asked me how to find a proper employer to work for. How to find out if a team you are going to join is kicking ass? How to check if the future team mates are good people? (By our definition a good person cares about his or her work, doesn't rush, writes unit tests, keeps the code clean and does many other nice things. :-) So how to find out if you want to work with them? These are good questions.

Mindset
Applying for a job is symmetric which means it's a process working in both directions. Of course you try to prove yourself worthy of the new job. There are many resources on the internet that tell you how to write your CV and how to behave during interviews, so you would not screw up. There are even guidelines for managers which questions to ask including the famous FizzBuzz. All these guides are targeting your value as employee and how to present it properly.

On the other hand your future employer has to show to you that he is worthy, too. The interviewer is his first representative and must be prepared well and take the interview serious. Later he or she might tell you about the company's generous compensation scheme or the team or the development process to impress you. In the end of the interview you are usually asked if you have any questions. This is the time to ask and so I do. During the past years I have compiled a list of questions that I ask during interviews. Today I want to share some of them.

Process
I always start by asking the Joel Test. Although it failed me in the past, I still believe it gives a good overview of the used development process. Then I ask the interviewer to define quality. Quality is perceived different by different people and the manager's idea of quality has considerable influence. Usually this leads to an interesting discussion if the manager is really interested in you.

Team "Theory"
The team I'm going to work with is important to me and I start asking about it right away. "How large is it? How is it structured? When was it formed?" A team needs time to form and I like to join high performance teams. So is it a real team where each team member found its place or is it just a group of individuals sharing the same room? Starting a gig with setting up a new team is risky if you lack authority to influence future hiring decisions. The team might not end as you would like it to be.

Team Spirit
Next I try to figure out the team spirit. "When did the last person leave the team and why? Why is there an open position? Are there any contractors on the team?" A high percentage of contractors is a bad sign. First contractors do not fully participate in teams as their engagement feels more temporarily. Second most contractors I know either have no idea about coding or are extremely prolific but then their code looks like hell. (But I'm sure this is a coincidence.)

How Does it Feel?
If all things are going well you might be invited to meet the team, which in some cases has the final word in the hiring decision. And even if not, a tour of the office never hurts. I always try to meet my future team mates and spend at least half of a day with them. How does it feel spending time with those people? Are they in a good mood or is there a dark cloud of fatalism hanging above them? Are they friendly and open minded? How do they communicate? You will spend a lot of time with them, so you better like them.

What Do You Know?
During this time I "interview" my future colleagues. Well, it's not a real interview, more a chat to figure out what makes them special. My questions just guide me during these conversations. And I would also tell them things about myself. Most likely they know better than me if I fit into the open position and the team or not. To get started I'm looking for someone who knows more than me. In our technical domain it's very easy to know more in some area than most developers. "So what's your background? How long have you been developing software? What were your most exciting projects? Was it cool stuff? Were you excited about them?" (Did you care?)

As these people are developers, I get more technical and ask them about their favourite Java framework or library. I like language fundamentals so Apache Commons fit me perfectly, but that's just me. Everyone has his or her favourite toys. Think about them, discuss them. Are they esoteric, mainstream, fundamental, boring? On the other hand the similar question, which is the first library to add to a new project, has only one right answer. It's not Apache Commons and it's certainly not Spring or Hibernate, but it's JUnit. Even if you do not develop test driven, you will need it sooner or later. If we happen to talk about design I always ask "What's your favourite design pattern?" I hope it's not singleton, because singletons are evil, all other answers usually lead to a good discussion about object orientation. After talking for some about what he knows and what I know I sum it up with my last question of this section, "What will I learn from you?"

Do You Care?
Next I'm looking for individuals that love to code, that care for their craft and are burning with enthusiasm. Asking about hobbies and how one spends his or her personal time doesn't sound related at first, but it is. The real question is if he or she does code on personal time, maybe is even an open source contributor. For example, some time ago I met an older guy and he didn't seem very enthusiastic. The whole team had impressed me so far and I was sure that he would just be a nine to five employee. I started asking him about his duties on the project but quickly moved to the area of personal time. It turned out he was into wireless network topology and played around with wireless infrastructure at home. He wasn't coding but still fooling around with technology. I was impressed.

Further I want to know "Which blogs do you read?" If you are interested in your craft you have to stay in touch, play around with new stuff and read books. The pragmatic programmers recommend reading four technical books each year. So "What was the last technical book you read?" Talking of books, "Who is Donald E. Knuth?"

What About Quality?
Ultimately I'm looking for software craftsmen and I wouldn't be genuine without diving into code quality and clean code. Everybody with just a faint interest in code quality, object orientation or self improvement knows Robert C. Martin, so I always ask if they know Uncle Bob. Finally I try to determine if I will hate this person every time he or she commits some changes to the repository: "What is most important about code? What is the worst defect for code? What is clean code for you?"

Warning
Let's finish with a word of caution: These questions help me figuring out if a future job is good for me but it's not foolproof. It happened that everything looked great and still the real job experience was awful. Also be aware that these questions result from my personal experiences. They need not to be good for you. Don't blame me if you end up in a group of coders from hell.

Code Quality Assurance v2

Last week I gave my presentation on code quality assurance, for the second time this year, and it looks like it will become an integral part of the lecture. That would be great. Maybe one or another soon-to-be developer will get interested by the ways of the craftsmanship and not become a Duct Tape programmer.

I was quite nervous in the beginning of the presentation as I had never spoken in front of so few people :-) Honestly, giving it the second time helped me a lot and I was much more relaxed and didn't hide behind my laptop most of the time. There were few students, but they asked clever questions in the end. Only one student complained about too much mathematics needed to solve the prime factors kata. Well it's not that complicated, but maybe I will try the word wrap kata next time.

Dear Students
There is a list of references at the end of the slides, only a few but you should read them. Go ahead, read them now! I will wait here. If you are desperate you might listen to the recording of last year's quality assurance presentation. It's missing the demos, but my explanations should give you a general idea of what's going on. Good luck and don't succumb to the dark side!