Monthly Archives: October 2017

You are browsing the site archives by month.

#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 →