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.

#RemotePairProgramming Ep 003: Strong Style Pairing with Michel Daviot

About

The second episode of this #RemotePairProgramming series is about Strong Style Pairing. My coding pairing partner this episode is Michel Daviot.

Strong Style Pairing

During Episode #002 Llewellyn was the Navigator in a Strong Style Pairing way. This episode I will be doing the same, but with my style. But there is also a challenge, given by my driver: Michel.

The Challenge

I don’t know at all the problem, and I have never heard of it. So I need to be navigating in a Strong Style Pairing without knowing the problem. So my solution is to go in small steps, to minimize the risk.

Remote Pairing Michel

Read More →

TDD as if you Meant It: Clean-up before next Triangulation (Episode 13)

TDD as if you Meant It: Clean-up before next Triangulation (Episode 13)

About

This episode is about failure to refactor because of trying to rush to the next step of Triangulation and taking too bigger steps. I sometimes use bigger steps, but I don’t feel comfortable because it can happen that I get stuck and then I revert. In this way I lose a lot of time. I usually prefer to go slower but make sure I have progress.

Consider this episode an example of how NOT to refactor.

Refactoring Rush vs Refactoring flow

Rushing to refactor can lead to a good result, but most often it leads to a situation where tests fail and we don’t know why. Most often the programmers I work with are rushing to refactor and don’t even observe the side-effects they introduce when they change the code. So they are not refactoring, but instead they are introducing defects because of taking too bigger steps. The most important aspect in this situation is that when I run the tests during the refactoring rush they are most often red. After being on red for 20-30 minutes I feel more and more pressure and I need to take a break. I don’t know what to do next, I feel stuck.

The most common reason of getting stuck or having red tests after finishing a refactoring is not using preparatory refactoring.

Refactoring flow means I always see a few next steps ahead. Also the most important aspect is that after each small change I run the tests and the tests are always green. Being in a flow feels good, and I often even forget what the time is.

Failure

So this episode, coincidentally or not it has the number 13, shows refactoring failure because of rushing and not preparing the refactoring. Please watch it and make sure you don’t do the same at home. Next episode will show you a better way to work, in contrast with this one.

Video

Check the video below with the codecast:

What’s Next?

Check the next episode on TDD as if you Meant it here: http://blog.adrianbolboaca.ro/evolutionary-design

On the same page you can find more ideas on Evolutionary Design.

Credits

Many thanks to Keith Braithwaite for creating the concept of TDD as if you Meant It

Teddy bear thanks to Erik Talboom for all the pairing, discussions that lead to so many twists we discovered together with TDD as if you Meant It.

Special regards to JB Rainsberger for the fun pairing we did using TDD as if you Meant It

 

TDD as if you Meant It: Separate Production from Test Code (Episode 12)

TDD as if you Meant It: Separate Production from Test Code (Episode 12)

About

When using TDD as if you Meant It we need to have a clear distinction between the test code, and the production code written in the test methods and classes. The more we dissociate the two, the clearer both production code and test code look. During this episode I made the final steps to separate production from test code. This is a final step of the triangulation of a specific concept.

Triangulation

When I started triangulating on the concept of Game, I made an analysis on inputs and outputs (called Behavior Slicing and explained in Episode 1), that lead me to write enough tests to be able to understand it. By triangulation in this case I mean adding enough tests to understand the links between the design entities. In some cases I need more tests, in others just a few. And of course the number of needed tests depends also on the experience of the coder.

Separation

When separating the two, we need to make sure everything is clear from any point of view: class names, package names, code structure in the IDE, etc. The code at the end of the separation needs to look as if we wrote it in a separate way all along. Whether we apply traditional TDD (where we write the test code in a separate file from the production code from the beginning), or we apply TDD as if you Meant It, the code structure needs to look the same. Of course, the design will be very different in many occasions because with TDD as if you Meant It we can zoom more on the simplest design possible.

Next step?

After this whole process of Behavior slicing to refactoring (Episode 3, Episode 4, Episode 5), to clean-up and to extracting production code I need to identify the next design concept to triangulate to. So stay tuned to see the whole TDD as if you Meant It process all over again, but with another concept related to the Game.

Video

Check the video below with the codecast:

What’s Next?

Check the next episode on TDD as if you Meant it here: http://blog.adrianbolboaca.ro/evolutionary-design

On the same page you can find more ideas on Evolutionary Design.

Credits

Many thanks to Keith Braithwaite for creating the concept of TDD as if you Meant It

Teddy bear thanks to Erik Talboom for all the pairing, discussions that lead to so many twists we discovered together with TDD as if you Meant It.

Special regards to JB Rainsberger for the fun pairing we did using TDD as if you Meant It

 

TDD as if you Meant It: Refactor and Clean-Up (Episode 11)

TDD as if you Meant It: Refactor and Clean-Up (Episode 11)

About

From Wikipedia we learn that

Code refactoring is the process of restructuring existing computer code—changing the factoring—without changing its external behavior

So clearly not any change in the code is refactoring.

During the last few episodes I extracted many design elements from the initial primitives, and this was refactoring.

Refactoring is different than clean-up. When cleaning I care about Clean Code, Coding Standards, Clarity, etc. Refactoring is difficult to make when I don’t have Coding Standards, because the duplication is more difficult to spot.

So my recommendation is

Every once in a while clean-up the code so that you can refactor your design easier!

Refactoring

The refactoring approach during this episode is mainly focused on design. There are many reasons to do refactoring: improve clarity, design, minimize defects, exploring alternatives, etc. These are the final stages in the TDD as if you Meant It cycle, when the design elements are almost ready to be separated completely from the tests.

Clean-Up

Cleaning up is important every once in a while. Without a clean code we cannot focus on the essentials, because there is too much mess. By clean-up I mean deleting the unused methods, delete the useless comments that initially were important, having the same structure in the same place, etc.

I really like having classes look the same: constants at the top, fields, constructor, public methods, private methods. And also having always the same spacing between methods, parameters, etc. All these have to do with the coding standards I use.

Coding standards are useful because they let me focus on what I need to refactor. I can easier see duplication between classes if they are structured the same.

Video

Check the video below with the codecast:

 

What’s Next?

Check the next episode on TDD as if you Meant it here: http://blog.adrianbolboaca.ro/evolutionary-design

On the same page you can find more ideas on Evolutionary Design.

Credits

Many thanks to Keith Braithwaite for creating the concept of TDD as if you Meant It

Teddy bear thanks to Erik Talboom for all the pairing, discussions that lead to so many twists we discovered together with TDD as if you Meant It.

Special regards to JB Rainsberger for the fun pairing we did using TDD as if you Meant It

 

#RemotePairProgramming Ep 002: Strong Style Pairing

About

The second episode of this #RemotePairProgramming series is about Strong Style Pairing. My coding pairing partner this episode is Llewellyn Falco.

Strong Style Pairing

The Driver is just the typist of the Navigator

Pair-programming is a technique where two programmers stay at the same computer and code together on the same problem. We have two roles: Driver and Navigator.

Driver = the partner who writes the code, and focuses on small details, on short term.

Navigator = the partner who understands what the driver writes and focuses on long term decisions. Typically the navigator’s focus is around the design, architecture concerns, clarity, conceptual cohesion, etc.

During a session of strong style pairing, the Navigator will take all the decisions. The Driver focuses on the small details, just to do what the Navigator has in mind. If something is unclear the two have a dialogue. The same as with traditional style pairing, both roles have the same focus: try to solve the problem as fast as they can with the highest quality possible.

Strong Style Pairing

Read More →

TDD as if you Meant It: Add Missing Tests for untested Branches (Episode 10)

TDD as if you Meant It: Add Missing Tests for untested Branches (Episode 10)

About

During the first episode of this series I added some initial tests where I didn’t cover all the cases. Now it’s the moment to run coverage on the code and check the areas where I am missing tests.

My intention was to show you how to fix such a branch that was not covered by tests in the beginning. We can add  missing tests even a lot later. So my mistake was intentional, because it’s a mistake I see very often and I wanted to show you what I do in this context.

Code Coverage with Tests

After extracting many classes and methods, I ca use code coverage to see which line(s) of code are not covered by tests. But code coverage is complicated. There are many types of code coverage:

  • Statement
  • Condition
  • Line
  • Method
  • Class
  • … and even more

So when you focus only on a metric, like code coverage, you need to know what to expect. You can read more at ISTQB.

Fallacies of Code Coverage

Let’s say we have the most complicated code in the world, and we want to have 100% code coverage:

If I add the test

then I will have 100% line coverage and 100% statement coverage. So then I’m done. I have added all the tests, right?!

But if then I add the test

it will surely fail.

So take care when you use code coverage as a metric, it can trick you into thinking you added all the necessary tests, but if fact you have many missing tests.

TDD as if you Meant it and Full Test Coverage

TDD as if you Meant It doesn’t guarantee full test coverage, you need to have tools and use them to check your work

You can have full test coverage, but you need to have in mind some good practices:

  • Ask yourself when adding each test if you covered everything
  • When you have second logical flows (if, while, for, etc) always check really well if you added all the needed tests
  • Use a code coverage tool to tell you which branch is covered by tests

So the technique of TDD as if you Meant It will give you the context of having full test coverage, but you need to take the necessary measures to make sure.

Prize for Pawel

Even from the first episode Pawel Duda told me that I forgot to add a test for the “nobody won” branch. And he was right, I didn’t add the test with the purpose of adding it a lot later and show you how I do this. So when we meet he will receive a prize from me.

Video

Check the video below with the codecast:

What’s Next?

Check the next episode on TDD as if you Meant it here: http://blog.adrianbolboaca.ro/evolutionary-design

On the same page you can find more ideas on Evolutionary Design.

Credits

Many thanks to Keith Braithwaite for creating the concept of TDD as if you Meant It

Teddy bear thanks to Erik Talboom for all the pairing, discussions that lead to so many twists we discovered together with TDD as if you Meant It.

Special regards to JB Rainsberger for the fun pairing we did using TDD as if you Meant It

 

#RemotePairProgramming Ep 001: Traditional Style Pairing

About

This is the first episode of a series of codecasts where I will explore, together with a remote (duh!) pairing partner, what remote pair-programming is. It is also about pair-programming techniques, and how they help us, or not.

My remote parter this episode is Llewellyn Falco.

Traditional Style Pairing

Two people stay on the same computer and code, for a specific problem.

But it is more than that. We have two roles: driver and navigator.

Driver = the partner who writes the code, and focuses on small details, on short term.

Navigator = the partner who understands what the driver writes and focuses on long term decisions. Typically the navigator’s focus is around the design, architecture concerns, clarity, conceptual cohesion, etc.

During a session of traditional style pairing the roles can stay the same, or they can change. But both roles have the same focus: try to solve the problem as fast as they can with the highest quality possible.

Read More →

TDD as if you Meant It: Experiment Design Alternatives when Stuck (Episode 9)

TDD as if you Meant It: Experiment Design Alternatives when Stuck (Episode 9)

About

During this episode you will see how I formulate experiments to decide where it is a good idea to get the design.

 

Refactoring

Evolutionary Design happens during refactoring. This episode is just refactoring, but with a clear purpose.  The purpose is to identify, with a clear hypothesis, if a certain design solution would be suitable. The word suitable is very unclear, so when formulating the experiment I want to make my expectations very explicit.

There are many reasons to do refactoring. During this episode you will see a refactoring that is focused on discovering (one of) the correct ways to create the design entities.

Experiments

When I formulate my experiments I take the following steps:

  1. Define the hypothesis
  2. What would be good if this experiment succeeds
  3. What would be bad if this experiment succeeds

Experiment example

  1. Hypothesis: “two by two”, “one by one” should be a class “BoardStructure”
  2. Plus
    No more primitives about BoardStructure in the tests
    All the structure will be in one place. Structural coherence.
    Some coupling is expected from the tests, but only one other class will use boardStructure
    Duplication will be removed in-between tests
    Clarity will be better because a cohesive design structure is extracted
  3. Minus
    Increased code complexity, because of a new design element

After the experiment

If the experiment succeeds, I can take the decision to keep the changes, but only if I am sure I don’t need more proof. And it’s not about lying to myself that the solution is ok. I really need to be honest to myself and if there’s the least doubt, I need to go back, revert the changes and try again by adding more tests.

If the experiment fails, I note down the situation and the solution. Either in my head, or I document it somewhere. It is important not to try it again in that context, because it would be waste.

I learn a lot more from failed experiments. I understand which are the solutions I should never chose and the solutions that work only in certain situations. If you don’t have at least a few failing experiments it means you are lying to yourself that you found the correct solution from the beginning.

Video

Check the video below with the codecast:

What’s Next?

Check the next episode on TDD as if you Meant it here: http://blog.adrianbolboaca.ro/evolutionary-design

On the same page you can find more ideas on Evolutionary Design.

Credits

Many thanks to Keith Braithwaite for creating the concept of TDD as if you Meant It

Teddy bear thanks to Erik Talboom for all the pairing, discussions that lead to so many twists we discovered together with TDD as if you Meant It.

Special regards to JB Rainsberger for the fun pairing we did using TDD as if you Meant It

 

TDD as if you Meant It: Create Duplication in order to remove it (Episode 8)

TDD as if you Meant It: Create Duplication in order to remove it (Episode 8)

About

After a couple of episodes when I showed how we can get out of TDD as if you Meant It to Traditional TDD. By Traditional TDD, I mean the TDD when you are allowed to create classes and methods before the test.

During this episode you will see how I focus on other primitives from the tests, and I add new tests in order to create duplication between the existing tests and the new tests. Then I remove the duplication by following the Rule of Three.

Duplication

Duplication can be of many types, but that is a different topic that I will follow later. During this episode I am focusing on structural duplication, meaning on the string primitives that still exist in the tests.

 

Video

Check the video below with the codecast:

What’s Next?

Check the next episode on TDD as if you Meant it here: http://blog.adrianbolboaca.ro/evolutionary-design

On the same page you can find more ideas on Evolutionary Design.

Credits

Many thanks to Keith Braithwaite for creating the concept of TDD as if you Meant It

Teddy bear thanks to Erik Talboom for all the pairing, discussions that lead to so many twists we discovered together with TDD as if you Meant It.

Special regards to JB Rainsberger for the fun pairing we did using TDD as if you Meant It

 

TDD as if you Meant It: Some Traditional TDD – part 2 (Episode 7)

TDD as if you Meant It: Some Traditional TDD – part 2 (Episode 7)

About

This is the second episode of an alternative evolutionary design approach. During the (Episode 5) I refactored the code to generate a builder. The alternative presented in Episode 6 and 7 is to stop using TDD as if you Meant It for a while and start using some traditional TDD.

Focus on the Problem

During this second episode for creating the builder with traditional TDD, I am trying to focus on finishing the problem. This means I am trying to get in a flow state, where everything works well at the end. Also that means that I am often taking bigger steps than what you saw in the first 5 episodes. This is because I consider the risk being smaller, and because I know where I want to get.

Refactoring

Because I am focusing on the problem, I am doing more refactoring. And the type of refactoring is faster, in bigger and more direct steps. I want to leave a nice code base behind so I try to have the best code I can for the moment. So then during the next episode I can use this code with ease.

Scale of Evolutionary Design

At one extreme I am in the point where I know exactly what I need. In this case any form of Evolutionary Design or TDD is useless. I might want to add automated tests (while adding the code or after) to perform the checks on the code just for regressions.
At another extreme I don’t know at all what I need, but I have the specs. So I start with them and I focus on the principles of refining the code concepts in order to extract the appropriate design entities.

During this codecast I will situate myself very close to the extreme where I know pretty well what I want. But careful to be sure you always introspect and clarify if you have all the information to take a design decision without enough proof. Your solution might be too complicated or just inappropriate.

Read More →