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.

Legacy Coderetreat: Part 1 – Introduction

Legacy Coderetreat

Blog post series

This blog post is part of a series about legacy coderetreat and legacy code techniques you can apply during your work. Please click to see more sessions about legacy code.

A bit of history

On 26 November 2011 I had the honour of being an attendee at the second ever Legacy Coderetreat, which was supposed to be the first one in the world. But my friend Johan Martinsson from Grenoble beat Erik and me to it. Anyway I was part of the second ever Legacy Coderetreat in the world, facilitated by JB Rainsberger. JB had come with this concept of using the Coderetreat format, but for legacy code.

At the beginning of the day he presented us the problem, like in any other coderetreat. The problem was an ugly trivia game and you can find the sources here. At that time the code base was translated, from Java, only in a couple of other languages. Now you can find almost any language you want, thanks to the worldwide community of passionate developers who translated the code base.

JB facilitated the event like you could find in here, with a lot of details. But in short we would start with a free session, then follow with Golden Masters, continue with Subclass to Test, Replace Inheritance with Delegation and then Pure Functions. After each iteration we deleted the code like in any other coderetreat and swapped the pairs.

I liked a lot the fact that JB started this idea, because I am a big lover of working with legacy code. And this Legacy Coderetreat is such a good way to practice. But I had some other ideas on how to make it different.

legacy-coderetreat

Legacy Coderetreat

Read More →

A community event: Bring your own code

Bring your own code

Last month I started a new community event idea. It is called “Bring your own code”, and I “stole” it from what Antoine Vernois is doing in the Toulouse Software Craftsmanship Community. You can find here the event page. Tomorrow we will have the second edition that you can find here. Let’s go a bit into the mechanics of this event type.

Why

  • You have a project and you want a second opinion.
  • Your code needs improvements and you do not know where to start from.
  • You just like to show some awesome code and give it as an example.
Bring Your Own Code

Bring Your Own Code

Read More →

Pair-programming game: Solution Seeker

Solution Seeker

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. Solution Seeker is one of them.

Introduction

Start programming only when you have at least three solutions.

I heard about this concept when I started being a programmer. It made some sense then, and now it has even more sense. Especially for problems when we care about: scalability, performance, speed, security, etc.

Purposes:

  • You need to find a very good solution for a problem. But the “good” part here needs to be very well defined in advance. What do you seek for: security, speed, scalability, etc.
  • The domain of the problem might be known or not to you. If it is known, you just want to expand you knowledge and find lateral solutions.

Concept

The two pairs sit down at the table and are not allowed to write any code until:

  • they think about at least three possible ways of solving the problem
  • they note on paper or in a text file the solutions
  • every solution has a clear definition of how the goals (security, speed, etc.) are going to be measured in order to make sure the solution is right
  • the solutions are prioritized: the simplest and with best estimated results will be the first one
  • they start prototyping the first solution and measure its performance
  • only if the first solution does not fit the criteria, the second solution is prototyped
  • go on until one good solution is found.

This idea is extremely useful for finding solutions on hard problems or in areas like startups and research&development.

Solution Seeker

Solution Seeker

Read More →

Pair-programming game: Farsight Navigator

Farsight Navigator

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 experienced navigators become better
  • Focus on long-term design decisions
  • Create design incrementally
  • Teach others how short-time design decisions can affect the design on the long term

Concept

Both the driver and the navigator need to know very clear which is the purpose, the destination, of their current code writing process. This concept works extremely well if you are doing Test Driven Development and you want to produce design incrementally.

The roles of the development are very well separated:

  • the driver is not allowed to think too much ahead
  • the navigator is not allowed to say anything about the implementation details unless some decisions would drive them out of their course.
  • in the case of conflict they need to stop and decide together which is the best approach

The driver

  • needs to focus only on the small implementation details.
  • will write code in small batches of maximum 5 minutes and will make sure the code is functioning well

The navigator

  • needs to see how the code will develop on the long run
  • if the driver tries to think too much ahead, the navigator needs to ask him questions until the driver understands why that decision is a bad one.
  • needs to be a very experienced person in programming and in software design
  • needs to keep their calm and explain always the objections to some path
Farsight Navigator

Farsight Navigator

Option
If you want to have an easier far-sight navigator session think to do a session of behavior slicing, value sampling and then order the resulting behaviors from simple to complicated. This activity will give you a first list of tests you need to implement. This list is just a temporary list, as some tests might be split, some new ones might appear or some of them might need to be discarded.

Outcomes

In the case of a problem where we cannot really know how to proceed we can apply this technique in production. If done well, we will have the simplest design possible, custom created for the problem we want to solve. We will write the minimum amount of code, but further we will minimize our possible design mistakes by focusing more on the design than usually.

This technique prevents us from doing mistakes that are hard to repair afterwards. You might say that you are doing TDD with special focus on long-term design decisions.

Whenever I used this technique, the efficiency of reaching a solution was astonishing from both the time spent and the quality of the solution point of views.

Remarks

This is the hardest pair-programming game I know. The purpose of this game is to make experienced navigators become better. I would recommend this only after at least 6 months to one year of continuous pairing from both of the pairs.

Have you read Dune by Frank Herbert? If you did not please read it because I guess you will like it. If you did read it, then you might remember the Spacing Guild and how they could guide the space ships by their special skills and protect them from danger. In the case of this game our navigator is like a Guild Navigator from Dune.

The navigator needs to  have special skills of pairing, programming, is extremely experienced in software design and is a very good communicator.

When will become a navigator with a far-sight?

Image credit: http://dictionaryproject.files.wordpress.com/2010/08/compass.jpg

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 →