Author Archives: Adrian Bolboaca

Adrian was involved in developing software for domains like energy, ecommerce, banking, customs and ERP/CRM. He has been working with companies from Netherlands, Romania, Italy, France and Germany, and he is knowledgeable in software technical domains like: clean code, unit testing, test driven development, simple design, emergent design, working effectively with legacy code.

As a continuous learner and challenger of existing ideas and concepts, Adrian is a supporter of movements that give new ideas on how to continuously improve software and that embrace the values of software quality and efficiency. He facilitated many code retreats in Romania, Belgium, France, Germany, Netherlands, Finland, Bulgaria and has a keen interest in serious games and using gamestorming for continuous improvement.

He is fluent in Romanian, English and French, but when it comes to programming languages he supports language agnosticism, since he strongly believes that a programming language is only a tool towards higher level software concepts.

As a constant participant to conferences and workshops, he is recognized for challenging ideas and getting people out of their comfort zone, not out of disrespect or lack of reverence for his peers, but out of his desire to show people that there are always things to learn.

“I try to be a continuous learner and a continuous teacher, because I think good software comes from the skills of the people that are involved in the process, on each and every level. Whenever I write code I focus on reducing domain complexity to obtain maintainable software. I love to develop software that helps companies to improve their business, to implement solutions that improve their internal processes and to motivate teams to use their capabilities to yet another level.”

Adrian works as a technical and organizational trainer and coach at Mozaic Works.

Pair-programming game: Yes, and…

Yes, and…

Blog post series

This blog post is part of a series about pair-programming games. To read about more please click see more sessions on pair-programming games.

Purposes:

  • Make the team members that always disagree try to build up on top of the ideas already presented.
  • Some members of your team are very stubborn and you want to show them that there could be other solutions than their own.
  • You want to improve solutions immediately when you see a smaller or larger improvement option.
  • You want beginners to feel they add value when pairing with more experienced people.

Concept

When working in pairs none of the pairs is allowed to delete the code of the other person. We are looking for a common solution, that both of the pairs will agree.

Why? Often I see that the more experienced programmers drive and give their solution as the best one (and sometimes as the only one). But even if you are not experienced, either with the specific language or framework or generally, you might have some good ideas for making the current solution better. In order to work on that attitude you can do ping-pong pairing with the rules Yes, and…

So the rules are:

  • none of the pairs can delete the code of the other.
  • at each step when switching from driver to navigator one needs to improve the existing solution and tests.
  • whenever one of the pairs tries to delete the code, the other needs to say “You should improve the existing one. Please go back and say Yes, and… I will do…“.
  • none of the pairs are not allowed to be angry on this request of not deleting code.
  • only unused code can be deleted, like for example after refactoring the code is not used any more. Both of the pairs must agree that the code can be deleted.

Sessions on this topic should be short, around 30-60 minutes. The first sessions should be supervised by a coach who will make sure the rules are understood and well respected. These sessions might become tiring, so make sure you choose a period of the day when you do not have other hard things to tackle.

Yes, and

Yes, and

Read More →

Pair-programming game: Beginner’s Mind

Beginner’s Mind

Blog post series

This blog post is part of a series about pair-programming games. To read about more please click see more sessions on pair-programming games.

Purposes:

  • You have very stubborn programmers in your team and you want to make his views softer.
  • To any problem, your team says there is only one solution, and that is their solution. You want to let them see there are always alternate solutions, which sometimes are better.
  • You had issues in the past with architectural or design decisions, just because the problem was not understood sufficiently.

Concept

A very experienced and neutral person, ideally an external technical coach, will pair with the team members one by one.
The rules are that:

  • the team member will be the driver
  • the technical coach will be the navigator
  • the technical coach is allowed to always ask beginner, even basic and stupid questions like “what are you doing”, “why are you doing this”, “tell me what is happening in this code”
  • the driver is not allowed to be angry by the beginner questions of the technical coach; the driver needs to always explain what is their current idea, how they can implement it and why they chose this path.

These sessions should have a specific, very clear topic. The technical coach needs to make sure that each member of the team understood the purpose.
The pair-programming session should not last more than 30-60 minutes as it is very tiring for both of the performers.

Beginner's mind

Beginner’s mind

Read More →

Pair-programming game: Silent Programming

Silent Programming

Blog post series

This blog post is part of a series about pair-programming games. To read about more please click see more sessions on pair-programming games.

Purposes:

  • Useful when you have talkative people in your team that do not agree or agree but do not write enough code for one task.
  • The code is not easy to read

Concept

The two programmers are not allowed to talk.
All the communication is made through code.
They are not allowed to use paper or write comments in the code or other files.

Silent Programming

Silent Programming

Read More →

What is pair programming?

Pair Programming

Blog post series

This blog post is part of a series about pair programming games. To read about more please click see more sessions on pair programming games.

About

Pair programming is a technique in which two programmers work together to solve a task. They work on one computer, ideally each having their own keyboard in front of them.
There are two roles: driver and navigator.

The driver writes the code and takes the short time decisions. The driver should trust the navigator totally for the long term decisions.

The navigator reads the code of the driver and gives meaningful suggestions on how the code could be better. Also the navigator focuses on the long term decisions and thinks the strategic direction the code moves to.

Both the driver and the navigator need to verbalize their actions and concerns and to speak on the code.

cat-pair-programming

Read More →

Pair-programming game: ping-pong

Ping Pong Pair Programming

Blog post series

This blog post is part of a series about pair-programming games. To read about more please click see more sessions on pair-programming games.

Purposes

  • Learn pair-programming easier
  • Force the “know-it-all” programmer to see other ways of writing code
  • Force the “know-it-all” programmer to collaborate more
  • Push for collective code ownership

Concept

The roles driver and navigator change often inside the pair.
This activity is like a game of ping-pong of the roles between the two members of the pair. They both can take short time decisions while being a driver and can spot strategic design decisions while being a navigator.
Refactoring can be made by any of the programmers on their turn, but only when the code and the tests are stable.

ping-pong

Read More →

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!