My Code Katas

I run various trainings for software developers, at least one every week. I have used many different exercises - called code katas - most of them curtesy of my fellow coaches, especially Emily Bache who maintains a huge collection of excellent exercises on her GitHub. And I created some exercises myself. I have collected all of them on a page, each with a short description how to use it. Enjoy!

Check out My Code Katas (permanent link).

Three Rules of Coaching Engagement

Last year software crafter and Kotlin enthusiast Oleksii Fedorov asked me about technical coaching. He was going to work with a small team and focus on technical enablement. He would do so by pair and mob programming with them for some time and later support them remotely if needed. During that time there would be no pressure or deadline to deliver new features so they could focus on improving.

Oleksii is a like-minded peer. I met him on several occasions in the past. He is fun to work with and considers teaching an integral part of pair programming. I did not expect any problems. He kept pushing me and made me think about my principles. In the end I came up with three points I like to make clear right from the beginning, i.e. set the ground rules of the engagement.

1. Manage expectations
Managing expectations is crucial. I learnt that the hard way during my Pair Programming Tour. Whenever I run a session, e.g. pair or mob programming and often also prepared workshops, I start with a discussion to collect expectations. For longer contracts I recommend to start with a dedicated meeting to do so. Usually expectations are fuzzy, like "I want to learn something", so keep pushing with questions like "How will you know it was worth it? How will you measure that you learned something?" and so on. In the end I want the team to come up with ways to measure their learning and define their own success metrics.

2. Learning is their responsibility
Oleksii planned for two weeks. In two weeks people will not change (much). Such a coaching engagement does not last long enough for much impact, rather it is a start of a (maybe even life long) journey of learning and improving. This is true from day one and during the initial meeting I make it clear that I am not a teacher. I will not push knowledge onto them to be forgotten the next day. To get something from working together, people have to participate, to engage, to invest time and effort into the topic. They will only get so much from it what they have put into it themselves. Learning is their responsibility.

3. Treat them as strangers
After removing the responsibility to teach anything - because learning is their responsibility - I feel less stressed. As coach I am still responsible for creating a safe space, providing content, managing exercises and a lot of other things. If someone does not want to participate or feels like doing something else, I have to be OK with that. Even being paid for "teaching" should not change that. My advice here is to treat the team members as "strangers", like we treat new visitors of a Coding Dojo. As a facilitator I try to help, but I will not oppose or coerce.

Feedback
Oleksii started the job soon afterwards. I was sure everything would work out fine. When we met again he told me that my three rules had helped him. 1. He collected expectations in the beginning and managed them while moving forward. 2. People understood that they had to invest and some participants even showed up for sessions during their free time. 3. People where entering and leaving sessions all the time, still he stayed relaxed.

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.

External Code Reviews

As Code Cop, I am sometimes asked to perform an independent code review. Before I start working on it, I ask for the goal of the review. What kind of results are expected and what will happen with these results? Which decisions will be taken depending on the outcome? Usually people know when the quality of their work is not that great, so why bother?

For example I was asked to review a code base because the developers had problems with their client. They were arguing about costs and regressions. I did not approve this reason, because in such a situation there is always a loser. When doing a code review, I do not want to shift blame, I want to make people aware of potential improvements and help developers learn and grow. So I persuaded the client to change the goal of the audit. Instead of looking for blame, I worked together with the whole team to come up with a list of necessary steps to correct their customer's problems. Understanding the way that software grows over time, it was reasonable to charge the client for at least some of that work. It became a win-win situation.

A Code Review is an Opportunity to Improve
So the goal of the review is highly relevant for the mechanism and success of such an external code audit. There must be a dialogue with the team and the audit's findings must be used for constructive feedback. That means discussing the results with development and creating a plan how to fix the critical issues. My findings are always concrete and raw - I do not like to create management summaries of elaborate slide decks. (When such reports were needed, development managers worked with me to create the slides they needed from my raw results.)

Sometimes I start a coaching engagement with a quick review of the team's code. It helps me to see the team's maturity and typical problems. With this knowledge I can target the top issues in Coding Dojos right from the beginning. Also when I help teams during re-engineering efforts, at least a partial review of the code base helps me to understand the problems we try to solve.

But Is It Practical?
Checking the code quality is difficult. I am not able to look at every line in the system, that is impossible. So I use static code analysis tools and metrics to get an idea about the code. But metrics are controversial because most of them do not measure what I am really looking for - clean code which is readable and can be maintained easily. The actual review of code is always based on samples. This is far from ideal.

An outsider can never know all technologies and reasons why a large piece of software is like it is today. That is why the developers are essential. To get usable results I am relying on them. I ask them about their code, let them create lists of their best and worst classes and discuss what I find and why I do not like it. To work like that, the audit must be a friendly action, performed in cooperation with the developers. When the goal of the review is to improve the whole project and developers are asked for their input right from the start, everybody is on board.

What I do
For a code review of a large code base, e.g. 500 to 800k lines of code, I try to get as much information about the code as possible. First I read about the used technologies if I am not familiar with them. Then I try to build the complete project and play around, opening classes randomly and following references. This is just warm up for getting used to the code base.

When I feel comfortable in the code, I start with the heavy lifting: First I run some tools to get metrics, e.g. JavaNCSS to collect the size and complexity of the code, or Chidamber and Kemerer to calculate coupling and cohesion numbers. Then I use tools to scan for smelly code or potential bugs, e.g. Checkstyle, PMD and others. These tools are very common and it happens that they do not find much - because the developers already use them - which is a great sign. But unfortunately it only happened once till now. Then I move from these line based analysis tools to higher level ones. I look for violation hotspots, code duplication, unused classes, Singletons (because I do not like them) and cyclic dependencies to name a few. There are many tools for Java but depending on the programming language, there might be less tools available. Anyway I still try to use at least one of each category.

The hard work is the manual part. I verify the critical findings of all tools, which includes a lot of navigation. Then I run some semi-automatic analysis, usually by searching. I look for compiler warnings, TODO markers, @SuppressWarnings, (too many) casts and instanceofs, catch blocks, ignored tests, useless JavaDoc comments and other things. As I check each finding, I have covered a lot of code so far - although somehow out of context. Finally I select a small sample of classes and read them from top to bottom.

In the meantime, I schedule time to talk to the developers. I ask them about known issues and where I should look in particular. As I said, people usually know where the skeletons are hidden. I ask them to show me how they build their software, how they use Continuous Integration and if they have coding and design conventions. If they have time I ask them to run some of the analysis tools I mentioned above and remove false positives. I do not have to do everything myself and every team needs someone who is familiar with these tools to use them from time to time.

Before I report the result to the customer, usually a manager of some kind, I present my findings to the developers and discuss my conclusions. I explain the results in detail until they fully agree with me. Sometimes I drop findings if the team explains their conventions. I make sure that my final report only contains real issues and has full support of the development team. Usually the team already starts working on the critical issues before the audit is officially concluded.

Teaching using Mob Programming

Since some time I am training young developers. I meet with different teams and we discuss topics like Pair Programming or I run hands-on workshops in the Coding Dojo format. Occasionally I pair program with single team members on difficult tasks as mentoring on steroids.

The first session
Last November one team I work with grew tired of Coding Dojo examples and wanted to work on real code while keeping the good atmosphere of our sessions. I envisioned sort-of a dojo in Randori style with everybody of the team pairing with me one after another. It ended with me being busy driving and all others navigating in different directions at the same time. Additionally, as teacher, I had to think about the proper action for the code and discuss the different proposals of navigators. It was difficult and showed many opportunities for improvement.

Enter Mob Programming
At the same time I learned about Mob Programming. Mob Programming is defined as all the brilliant people working at the same time, in the same space, at the same computer, on the same thing. That means that most of the mob's work is done sitting together in a group work area. All the necessary skills are present together in the same room, so there is no waiting time. If you have never heard of it, I recommend watching this presentation by Woody Zuill about Mob Programming, presented at the Oredev conference last year. Woody's team is using this technique since some time for all production work.

My Sessions
Inspired by Mob Programming I applied some of its concepts to my sessions. For example I never drive and I also do not navigate. Instead I try to meta-navigate the team of navigators. (Or sometimes I simply dominate everybody and tell the driver exactly which keyboard short-cuts to type. ;-) In the following sessions we refactored some code and created unit tests. All these sessions worked out well. Now, after running more than ten Mob Programming sessions with various teams during the last year, here are some things I noticed:

Communication
Mob Programming enables communication. In one of the first sessions, the architect of the team saw something in the source he did not like. He mentioned it to be an architecture violation but the other team members did not know this aspect of the architecture. It was amazing to see them talk. Although being on the same team they had not talked about it before. It is known that regular pair programming spreads the knowledge throughout the team and Mob Programming does even more so.

Participation
"Mob learning" differs from regular "mob work". Some people like learning sessions less than "the real thing" Also as in any team and any team activity some are more interested in the session than others. But usually participants are engaged, probably due the good communication. One major factor for active participation is the team size. Sessions with too many people do not work out well. Larger groups split into subgroups with their own agendas. I recommend group sizes of ten or less people.

The teams I work with are mixed teams with members of different experience and skill. It happens that some junior members cannot follow a high level discussion and zone out. I believe this is a symptom of the group needing more knowledge sharing and communication in general. I guess this does not happen to experienced "mobs" but I do not know. As moderator I try to get all people engaged and ask the seniors to explain the problem to the whole team because "the team needs to know". I also move forward very slowly so everyone is able to get along. This is even more important in the end of the session as people get tired and zone out more easily.

Exhaustion
Due to their active nature "mob sessions" are quite exhaustive. Ten minutes of break each 50 minutes of work help to keep people fresh. Also regular rooms run out of fresh air quickly, so I open windows as much as possible during these breaks. Most meeting rooms I have been to have the projector on the shorter side of the room, so almost all people have to sit with their heads turned. This is uncomfortable and tiring when sitting like that for several hours. While there are no dedicated work areas for mobs, internal training rooms are better because they are usually arranged like classrooms. But I have yet to find the perfect mob working area in the enterprise.

Topics
In my Mob Programming sessions I want to show the team certain techniques, e.g. splitting a large class. The session needs a defined, explicit goal and everybody needs to be clear about his or her expectations. The format works well for showing a work-flow from end to end. Also people like sessions with big structural changes, e.g. refactoring towards a pattern. On the other hand they do not like extracting small structures, discussing names and other clean code related activities. People do not feel progress there. This might be a drawback of working with real code, the urge to make progress is higher than in a dojo. Maybe these sessions are only appropriate after the participants have gained a certain level of competence by attending Coding Dojos. Even with successful mob sessions I mix in a Coding Dojo every third time at least. In the dojo people work on the details and practise the basics. In some way mob sessions are orthogonal to dojos and as such a great addition to our learning tools.

Driving
I rotate drivers every ten to 15 minutes, as proposed by the Mob Programming guide to keep people active. Usually there are participants who do not want to type. These include junior team members, who probably are afraid to get criticised in front of the team, and on many occasions female developers. If someone does not want to drive, I ask why, but till now did not get any clear answer. I guess some people do not want to type because they are slow. Once a senior guy refused but then did drive. He was horribly slow and used no short-cuts at all. He even did not find the rename refactoring in the Eclipse menu. It was embarrassing.

Moderation
These kind of work is more demanding for me than dojos or even theory sessions. I rehearse my theory presentations and experiment with the planned kata before a dojo, but it is impossible to prepare fully for such a mob session. I ask the team to send me the code we will work with a few days before and then work through it in detail. Knowing the code up front makes me feel more secure and saves time because I do not have to read the code during the session. Such a session is team work and I do not have a strict outline except the defined goal. In fact I can never be sure about the right thing to do because it is not my code. I have no idea about its requirements, history and constraints. This is stressful because as mentor I am asked for guidance which I might not be able to give. It happens that I have to say that I do not know, which is not a problem but still makes me feel that I failed.

Conclusion
I am facilitating Mob Programming sessions since almost a year with different teams in different companies. Some worked out great, some did not. Some were fun, some were just exhausting. Should you try it? Maybe, I do not know. Do I recommend it? No, I stick with Woody's style of "not recommending", No I do not recommend it, I am just sharing because people have been asking about it. But I am genuinely interested in this mode of working and will continue to experiment with it. Unfortunately I never participated in a real session, working on production code. That would be another kind of experience. (Hint, hint! All you mobs out there, I am open for your invitations ;-)

TDD Exam Questions

Last year I ran a three day in-house training on unit-testing and TDD using Eclipse. I wanted the course to be as interactive as possible to keep the attendees engaged all the time. Besides my slides I carried out exercises like Jason Gorman's TDD from Hell and played short movies to keep the content varied. At the end of each chapter I showed a slide with a few questions about the topic just covered. These questions gave the audience a break to recall the content just studied and reflect on it before moving on. I searched for such questions but did not find any, so I had to come up with my own.

These are my sanity-check questions. They are not complicated or long-winded, just simple questions to verify if the content was understood. Some questions also served as a base for further discussion. The developers in the audience were exposed to TDD for the very first time, so I kept them simple. If you are a seasoned developer I am sure these questions will not challenge you at all.

Unit Testing with JUnit

• What is a test fixture?
• Which assert is used to compare the values of objects?
• What about assertTrue(true);?
• What about assertTrue(a.equals(b));?
• How to test for an expected exception?
• What about System.out.println(...); in tests?
• How to data-drive tests?
• How to time-out tests?
• How to test the contents of a private field? (This is a trap, the answer is not to test it but to change the design.)
• Does full code coverage mean the code is fully tested?

Test Driven Development

• What are the benefits of using TDD?
• Is TDD primarily a testing technique?
• When do you write tests? (This is a joke and the expected answer is "all the f*cking time" according to Bryan Liles' TATFT.)
• What should you do when you cannot add another test?
• If the code passes all the unit tests why should you still change (refactor) it?
• Why not refactor on a red bar?

Mocking and Test Doubles

• Why use stubs or mocks?
• How are objects called that are passed around but never actually used?
• How are objects called that can return fixed values in answer to calls made.
• How are objects called that can verify the behaviour of the system under test, in addition to using asserts to verify its state.
• What is used for testing state?
• What is used for testing behaviour?
• What is a spy?

Refactoring

• What is your favourite Refactoring?
• How do we refactor? (This is a word play and the expected answer is mercilessly.)
• Should Refactoring and adding new code be done at the same time?
• During Refactoring, how long does your code not compile?
• During Refactoring, when should we run the tests?
• What Refactoring can be used when a method is too long, has duplicated code or Feature Envy?
• What Refactoring can be applied to long parameter lists?
• In Eclipse, what do the short-cuts Alt-Shift-R, Alt-Shift-L and Alt-Shift-M do?

Working with Legacy Code

• What is Legacy Code?
• How can you break dependencies?
• What are Singletons and why are they evil?
• Do you write them?

Using these questions, small exercises and short movies I kept the participants fully engaged for a whole day of TDD theory. It was awesome!