Monthly Archives: November 2017

You are browsing the site archives by month.

#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