Category Archives: Clean Code

Why should you facilitate Code Retreat?

Leave a reply

Less than a week ago was another Global Day of Code Retreat. Few thousand people in few hundred cities spend a whole day working on improving their skills. That part doesn’t seem strange anymore, devs are doing such things all the time.

But during after party one of the participants asked me why am I doing it? Why spend a lot of time and effort on something nobody pays you to do? Participants have obvious benefit – they get better developers, they learn. Some openly admit that they treat it as a free training. But what about organizers and facilitators?

That question caught me off guard. I just wanted to organize this Code Reatreat for a while, even since I moved to New Zealand. But why?

1. Teaching (or facilitating) is a great learning tool

Some people think that teacher or trainer or even random CR facilitator has to be an expert and surely knows more than people who are “just” attending the event. That might be true, but more often it is not.

There is a good reason why it is said that if you want to truely learn something you should teach it to somebody else. Facilitators learn a lot during the day. Maybe sometimes even more than participants, because they have more time to observe and analyze approaches of multiple pairs. They see various approaches, compare them, think about them, try to come up with good questions.

We know there is more than one good way to solve a problem, but unless we have a big group of people working on the same task, we don’t realize how different ideas people have. Then we can discuss and compare multiple solutions, see their strenghts and weaknesses. This does not happen often at work, because we don’t give the same tasks to multiple groups.

Being a good facilitator is not easy, you have to practice asking smart questions – those kind of questions that guide, but don’t give away the answer. Also by trying to help people you have to organize your knowledge better. You are deepening your understanding of familiar concepts. You see them in a completely new contexts. You have to explain the same thing over and over, in various ways and by doing so, you discover what really matters, you get to the essence. In short – you deepen and distill your knowledge.

Apart from technical aspects, facilitators also have to learn basics of teaching, such as “crowd control” (make sure one person does not dominate the whole retro, try to encourage shy attendants to speak up), clearly explaining new concepts (might seem trivial unless you actually give it a try), providing encouragement, helping to get “unstuck” when somebody just sits there and stares at the screen, finding the middle ground between people “just doing it” and giving the answers away (also called proper guidance).

2. Moving the industry forward

Contrary to what is told, still too many developers seem to finish their education when they leave university. Some need to keep up to date with newest frameworks and buzzwords, but it still amazes me how many people in our industry never encoutered the basics such as proper testing or working in pairs. This is something we are not taught at the uni and not all companies pracitce it.

At every CR there are some people who never wrote tests or don’t feel comfortable with them (yet). It is really amazing that after just 5-6 sessions they say that it was easier than they expected. They discover the benefit of having more confidence in the implementation and are keen to introduce those concepts at work (or just practice it more diligently).

For some this is the first opportunity to try pair programming. Those people are very excited about the collaborative approach, they feel inspired by seeing in how many ways the same problem might be approached by different people, they discover that when they cooperate, the end result is way better.

Many participants commit to promote those two practices at their workplaces.

3. Bringing companies and communities together

In some cities companies are not eager to cooperate. Sometimes they say that if we work with X, they do not want to have anything to do with us. On the other hand, there are some companies that never got involved in community events, but if you ask them they are very keen to participate. Maybe nobody ever asked them, maybe they simply never thought about it. In such a case that might be the way to get them more involved in other activities as well.

For example one of our current sponsors insisted on booking few spots for people from their company. Now they are very keen to organize similar events. Since a few of their employees attended, they are in a very good position to make it happen.

The other thing I really like about Code Retreats is that they are technology agnostic. You meet people using C#, Java, Ruby, Clojure, Python, Haskell, JavaScript… Sometimes that means you just have a quick exposure to different paradigms and make a few interesting observations, but sometimes it inspires you to learn a completely new thing or become a member of another community group. It definitely broadens your horizons.

4. Spreading hunger

A while ago Steven Jobs gave a really great graduation speech. In it he encouraged people to “stay hungry, stay foolish”. I think this is a great state to live in. Always on the lookout to learn a few new things, to get better, to make world a better place. People do not always are lucky enough to be in a job where they have great role models, but they are very likely to meet fantastic people at event like CR.

Sometimes attending such an event opens up a completely new world for somebody. It turns out to be a first step in a very long journey towards mastery. It might be this tiny event that “awakes a hidden software craftsman within”.

Some time ago somebody inspired me and helped me to make that step. I never looked back. Now I want to give it back and share this experience with as many people as possible. I believe organizing CRs is one of the ways to make it happen.

P.S. If you’re thinking about organizing or facilitating the CR, but don’t know where to start, feel free to ask in comments or on Twitter. I’d be more than happy to help!

Legacy Code Retreat

Leave a reply

Recently we  (together with Seb) organized a Code Retreat event in our company. It was not the typical event you see during Global Day of Code Retreat, for a few reasons. First of all, it was internal, only people from our company were present. Therefore, the diversity of tools and languages was not as high as usually. Then, it was organized during work hours. Finally, it was a Legacy variant.

What exactly was the point?

Some people might question, whether organizing internal company event of this type makes any sense. After all, one of the fundamental rules of retreats is attending them in your free time, only because you strive to improve your skills, not because your employer requested it. In our case there were a few reasons for choosing that format:

  • We knew there are a few skills that devs from our company needed to improve (refactoring, following simple design rules, writing tests and testable code, etc.). We knew exactly what issues come up in various projects and decided that getting familiar with those basics is the first step towards making our codebase better.
  • We didn’t have any training budget, therefore we couldn’t hope for getting a professional trainer. Even if we did, probably it wouldn’t be worth spending that money for learning the basics we intedned to cover.
  • Many people work long hours, so asking them to do something extra in their free time seemed a bit too much. Even then, getting some people out of a project even for one day turned out to be extremely difficult, so we needed an official, approved event to allow people to spend some time learning.
  • We wanted to provide opportunity for people to practice new skills. Making a presentation, organizing a “Lunch and learn” or anything of that kind, for sure wouldn’t work for us.

What did we do?

  • We’ve got source code for JBrains’ Trivia game from here. We paired with Seb for one hour to get GoldenMaster done, in case some people don’t finish it during first session (proved to be useful:)).
  • We organized a short intro to Git a day earlier (especially useful for short refactorings session).
  • We run sessions, each 45 min., followed by a retrospective and break. Since retros between sessions were very short, not everybody had to answer questions.
  • In the end we asked every person to share what they learned, which session they liked the most and what will change in their work from next Monday.
  • After that we hit the pub for a quick beer:)

How did it go?

We were surprised and very glad when people said how many new things they learned from each other. Without any suggestions on our side, a few people said exactly the things we wanted to address, regarding changes in how they would work from now on. People also got very excited about what they learned, some encountered new tools that their colleagues were using, seems like the event left them hungry for more (which was one of our two main goals).

Of course, work is much harder than what we do during reatreat, in reatreat we don’t have databases, codebase is tiny, we don’t worry about deadlines and pressure from management.  So I’ll follow up on this, want to see whether people managed to implement those new ideas at work and what challenges did they hit.

Detailed description of sessions:

Session 1 : Golden Master – Create a test for the game, changing as little code as possible and covering the largest possible number of cases (challenge – change only one line). Keep the tests and use them in later sessions.

Retrospective questions:

  • How much did you change?
  • How many test cases did you cover?
  • What challenges did you hit? How did you deal with them?

Session 2: “Make the code better” – Using whatever techniques you’re familiar with make the code look better (whatever that means to you)

  • What do you think about this codebase? What problems did you hit?
  • How did you change code (e.g. extracting methods, extracting classes, removing duplicates)?
  •  How many tests did you add?

Session 3: Pure functions – Extract methods that do not have any side effects and state.

Retrospective questions:

  • How many methods did you extract?
  • What methods did you extract?
  • How many tests did you add?

Session 4: Single responsibility principle – Make sure each class has a single responsibility.

Retrospective questions:

  • How many classes did you extract?
  • What classes did you extract?
  • How many tests did you add?

Session 5: Short refactorings – There’s an imposed 3 min. limit for refactoring and covering your change with a test. If you don’t manage to finish before time elapses, revert your changes.

Retrospective questions:

  • How many refactorings did you manage to finish?
  • What did you learn in this exercise?
  • Did you use Resharper and keyboard shortcuts?

Session 6: No mouse or short methods or eliminate conditionals – Pick one of the three tasks (or combine them:)): either do not use mouse or eliminate conditional statements from your code (ifs, switches, loops) or make your methods shorter than x lines.

Retrospective questions:

  • Which task did you choose?
  • How many conditionals did you eliminate?
  • What techniques did you use (popular ones are using dictionaries or modulo function)?
  • How many methods did you add?
  • In the end, how many of your methods were longer than x lines?
  • How many tests did you write?

Specification By Example applied

Leave a reply

Humble beginnings

This was a very ordinary day, ordinary meeting, when one of my colleagues came up with a proposition of writing tests using Specflow. If I remember correctly, he watched a presentation from NDC and the idea appealed to him for some reason. We decided to give it a try and write tests for one of the old modules in our system.

We’ve already had some existing tests in this module, but we wanted to increase the coverage. Since we didn’t start from scratch, Konrad managed to get the first tests running pretty quickly. Few days later he was showing us how to get started. Some time later we decided that we could use our slack time for writing Specflow tests.

A few months later I was thinking about making a presentation at a local .NET user group. I mentioned it to my team-lead in our one-on-one meeting. He suggested that I could investigate the concept of Specification By Example a bit deeper and share our practical experiences. I read a few books, I made a presentation, then another, the idea stayed with me since then for good and I  still keep learning about it.

What’s the big deal?

Soon enough we started noticing benefits. The separation of abstraction levels (pseudo-natural language vs code) influenced the way we were thinking about the problems under test. We started discovering more and more inconsistencies. We documented them and discussed with client. We asked more questions than ever. After a while we questioned everything, just on principle.

Then we applied the concept to other areas, where we didn’t introduce Specflow and didn’t even want to. When requirements were unclear, we used examples and tables, we used natural language to provide specific scenarios, making sure that we and our business experts were on the same page. The side effect of this was that we started focusing more on the “why” part, on the big picture of the problem. We learned that some of our assumptions are incorrect, that we automatically add constraints that our experts didn’t came up with (e.g. they were ok with some kinds of temporal data incosistency, which seemed crazy for us), that sometimes we use the same words to describe different concepts (apparently “future date” sometimes might be equal to “last week”).

The scenarios provide a very neat framework for communication with business users. Our experts were in fact quite “techy”, which made things more difficult. Sometimes they used technical concepts in a different way than we. Sometimes they had “how” ready, before we even knew “what” we are supposed to do. Scenarios were a good entry point for getting conversations started. And those conversations were different from those we had before. They naturally kept us communicating on higher abstraction levels, talking about business, not ints and database indices. Thinking about the minimum set of key examples helped us spot potential issues even before we started implementation. We caught a few incosistencies in business rules without writing a single line of code.

We got it all wrong! Yet… it worked

I find it ironic, that when I started digging deeper I learned that we got it all wrong, we made all the possible mistakes, started from the completely false assumptions… and yet, it brought us a lot of value. How was that possible?

First of all, we had the “idea” champion. Konrad wored very hard to make it work, he started the whole process, provided some initial examples and occasional tweaks later, he tutored other people on the team how to use it. I think that if that idea “was given” to us from the manager or some external team, we would not care that much. But it was ours. Konrad wanted it to succeed and we wanted him to succeed in his efforts. So we tried hard to make it work.

Then, the tool itself was interesting. It was something new, something different, so a few of us were actually happy to spend our slack time writing more tests (by “us” I mean developers!). That meant that more tests were written, then would be if we used, say, NUnit for the same thing.

Our Specflow scenarios were far from ideal. We tested on the lower abstraction level than we should. We used too many examples. We didn’t share our scenarios with clients (sometimes we copied them to email, but they didn’t know it’s anything more than plain text). Tests organization probably could be better.

So we might say that even if we didn’t fail from the technical point of view, from the point of proper tool usage, we didn’t have much success with it either. But that wasn’t that important. We still could get the benefits the tool brings. I think that in the end we could just throw away all the tests and never use Specflow again, that wouldn’t matter that much. Even then we’d get some value from getting familiar with the tool.

To me the main benefit was that we learned to work differently in the process, now we don’t need tools and frameworks anymore to get the conversations started. I really experienced that I, as a developer, am also responsible for requirements and understanding the busines side of things. That I can (and should!) ask questions, clarify, propose alternatives and warn about difficulties as early as possible.

Of course, we could use a different tool or not use any tool at all. Also, there are other benefits to BDD or Specifications (I’ll write more about it in a separate post). But I think it’s pretty cool that we didn’t have to fight for budget, attend any formal trainings or look for communication experts, to learn all those things. If it worked for us, I guess it can also work that way for other teams.