Category Archives: Workshop

Brutal Refactoring Game

Brutal Refactoring Game

I wrote a post on the history of Brutal Refactoring Game, you can read it here.

In this blog post I want to tell you more about the workshop and about my experiences while facilitating it. Also I will add some tips for facilitators that want to try themselves this workshop.

The purpose of this workshop is learn what refactoring is, why it is so important to do refactoring often and immediately after you spot some coding smells. Often I ask programmers “when are you doing refactoring?”. The question has a vast number of answers from “when I think I need to”, to “once a month” to something like “every couple of tests”. But seldom I hear that programmers do refactoring all the time, in the minute the tests had passed from red to green”. This is where the format comes into place.

Brutal Refactoring Game

Brutal Refactoring Game

Read More →

The history of “Brutal Refactoring Game”

The history of Brutal Refactoring Game

Last year I was thinking about a session during which attendees would learn how to focus on refactoring. I had some thoughts about this: we would need a list of coding smells, and have some cards to give the attendees that had that coding smells in their code. Now the obvious question was: how can you have coding smells if you do not have a code base? I thought about it, and then I figured it out: during coderetreats I anyway see legacy code after 10-15 minutes. So if this session would take 90-120 minutes we would have no issue with finding coding smells.

The first thing was: of course I will ask people to do pair-programming. This is how you learn a lot!

I came with these basic thoughts to Alex, and we had a chat about this session. Initially I had wanted to print one index card for each of the coding smells. But Alex helped me simplify the concept by creating a numbered list of coding smells that would be projected on a screen. Then we thought: we could use index cards just to write the number of the coding smell.

Refactor your code commrades or it s the gulags for you

Now the question was: how do we do this? How can we enforce the coding smells? We thought about it and we said “we love clean code, so we could be something like a dictator”. Then we both had in mind the concept of “Benevolent Dictator“. The sessions was starting to shape-up. The benevolent dictator was a key factor in the environment we wanted to create: learn and play.

Read More →

Taking Baby Steps

Taking Baby Steps

I wrote a post on the history of Taking Baby Steps, you can read it here.

Now I would like to tell you more about the workshop and the technique itself. While coding, for me it is very important to be focused on one idea. Why? Because this is how programmer mistakes appear in the code; some people tell them bugs. The other thing I am interested in is to have an undo button for every change. This is why I want to commit every 1-2 minutes.

The rules are the following:

Steps

  1. Setup source control repository.

  2. Setup a timer for 2 minutes interval when you start.

  3. Write exactly one test

    1. If the timer rings and the test is red then revert and start over.

    2. If the test is green before timer rings then commit.

  4. Restart timer (no discussions in between timers)

  5. Refactor

    1. If the timer rings and the refactoring is not complete then revert and start over.

    2. If the refactoring is complete before the timer rings then commit.

  6. Restart the timer (no discussions in between timers)

  7. Go to 3.

  8. When session time is up delete the code.

Read More →

Architectural Kata – Budapest

Architectural Kata Budapest

Following the invitation of Zsolt Bodo I facilitated an Architectural Kata in the Budapest Agile community. The purpose of the session was to let the attendees speak about architecture and I was merely a facilitator. My other role was the customer, clarifying the requirements whenever the audience requested.

The concept remains the same as for the first Architectural Kata I facilitated: you cannot be a good architect if you do not have the experience. An architect creates 10-15 architectures during the whole career, so we need to practice to become better architects. This session is exactly a repetitive exercise of creating architectures for given, unclear, requirements.

Architectural Kata Budapest

Architectural Kata Budapest

Read More →

We love legacy code!

We love legacy code!

 

 

Architectural Kata

Architectural Kata

I first got into contact with this notion at the SoCraTes conference in 2012 when Benjamin facilitated not one, but two sessions. Unfortunately then I could not have attended as I was too tired from the sessions I had facilitated.
Last year I met again Benjamin at the XP Germany conference. Then I really attended his session. You can read more about that here.

We (mostly my brother Alex) decided to bring this Architectural Kata to the Bucharest community. And last week we had the first one.

The main idea behind this concept is that you cannot be a good architect if you do not have the experience. If you are an architect you create maybe 10-15 systems in your life, so that is surely not enough to be a good one. So with this session we do a repetitive exercise of creating architectures for some requirements.

Architectural Kata

Architectural Kata

Read More →

The history of “Taking Baby Steps”

The history of Taking Baby Steps

Let me tell you a story on how I thought about teaching other programmers how to take small steps to help them minimize the mistakes by focusing on a small thought.

Taking Baby Steps

Taking Baby Steps

A couple of years ago I was working on a legacy project, meaning I did not know anything about the business, and it was written in Delphi .Net which was totally unknown to me. I needed to translate this medium-sized code-base from Delphi .Net into .Net / Silverlight.

Read More →

TDD as if you meant it, Turku, Finland

TDD as if you meant it Turku, Finland

Because of my plane connection from Bucharest to Turku which was not so great, the trip lasts around 12 hours all in all, I needed to stay from Friday to Tuesday next week in Turku. So why not trying to organize an event shorter than the coderetreat, for two hours in the evening like I did a lot of times in Bucharest. Aki was really receptive to my idea and in a matter of hours he found a host, and announced the event to the local community.

TDD as if you meant it, Turku, Finland

Read More →