Skip to content
Selection Pressure Code Cast Part 1

#RemotePairProgramming Ep 005: Adi & Julian – Evolutionary Design with Selection Pressure (part 1)

About

Selection Pressure. What is it?

What is Selection Pressure? First of all let’s give a definition from Biology

Any cause that reduces reproductive success in a portion of a population potentially exerts evolutionary pressure, selective pressure or selection pressure.[1] With sufficient pressure, inherited traits that mitigate its effects — even if they would be deleterious in other circumstances — can become widely spread through a population. It is a quantitative description of the amount of change occurring in processes investigated by evolutionary biology, but the formal concept is often extended to other areas of research.

During this episode we will apply the concept of Selection Pressure from Biology to software development that Julian Ghionoiu came-up with. So check the video to see more!

The third episode of this #RemotePairProgramming series is about Evolutionary Design with Selection Pressure. And, as always, I have coding coding pairing partner, that during this episode is Julian Ghionoiu.

Selection Pressure

Remote Live Coding with Grenoble TDD as if you Meant It

TDD as if you Meant It: Remote Live Coding with Grenoble (Episode 15)

TDD as if you Meant It: Remote Live Coding with Grenoble (Episode 15)

About

At SoCraTes France I paired with Rémy and Johan to show them how I code using TDD as if you Meant It. We had a few hours to try it, and then Rémy told me he would like me to present this to the Grenoble Software community. So this is how we arranged a remote live coding session on TDD as if you Meant It.

During this session I am using Poker Hands as a problem, and I start with the usual Think-Red-Green-Refactor and Behavior Slicing. Then a lot of refactoring is going on. I invite you to watch the video and come with questions and improvement ideas.

Debriefing

At the end of the remote live coding session we had a remote discussion about what happened. Here is in form of Q&A.

Question: When you want to show the duplication to be sure it is not accidental, you try to duplicate three times the same code. Do we need to do this when we do just copy/paste? It doesn’t really help the tests.
Answer: The fact that you can duplicate the test it shows it is easy enough and we don’t necessarily use the Rule of Three. But there are other cases when it’s more complicated and just duplicating the tests would not show the same. And there is still some duplication that doesn’t prove in the production code. We find that it’s not really the same behavior, and it’s often a surprise. The fact that I can make the duplication the third time is just making the point that we need to remove the duplication. Otherwise I need to search for duplication in another way.

Question: It seems that we create these tests just to follow the Rule of Three, not because we want to.
Answer: I don’t want to create the tests just to follow the constraint of The Rule of Three, I just want to be sure enough that what I am doing is on the good path. I don’t want to rush into refactoring. It is a question of how well you know your domain and how much you trust your instincts. The TDD as if you Meant It comes with the idea you don’t trust your instincts and you need proof.

Question: If you want to create some duplication, we can use parametrized tests.
Answer: Yes, for the tests that are duplicated we can use parametrized tests and compress the code. And probably at the end there will be very little code.

Question: Have you detected different styles of doing TDD
Answer: Yes, but most of the problems I see that people fail to respect the rules and don’t find a way to respect the rules. But of course, there are very different styles. Some go very functional, some like to use more state, I go in very small steps. I like to go in very small steps and focus on triangulation. I like to use it as a machine that is generating duplication in all these tests and then because I have duplication, I extract the methods and the classes. You do need to refactor a lot. And you need very good tools to refactor automatically.

Question: I think this technique is a lot more difficult to use with Legacy Code, is it?
Answer: Yes, it is more difficult. But you don’t need to use it too often with legacy code. I can use it on legacy code, but first of all I surround the code I want to change, put some interfaces around it, and then use the same steps to generate the code to rewrite it with very small steps in a simpler way. There might be situations where I prefer to rewrite some legacy code instead of refactoring. When using TDD as if you Meant It with legacy code you need to take very small steps, and do a lot of refactoring in small steps, understand the flow of dependency injection and understand the patterns. All these I learned by using TDD as if you Meant it a lot. I think it helps you to refactor better. You have this refactoring muscle. With legacy code you have a lot of primitives and so much misplaced code. Here with new code you have the same, and you need to understand how it makes sense to put it together. So I think you can use TDD as if you Meant It especially for the refactoring part.

#RemotePairProgramming Ep 004: Adi & Michel Daviot – Michel as Navigator (part 2)

About

During this episode from the #RemotePairProgramming series we continue the exercise from previous episode. My coding pairing partner this episode is Michel Daviot.

Pairing Techniques

Question (Michel): When would you use this remote pairing techniques and pairing (like Strong Style, Farsight Navigator, etc)?
Answer (Adi): When people are very used to their code, but don’t know how to refactor it, it is very useful to use Strong Style, because the Driver would know how to navigate around the code, but won’t know how to refactor or use a specific legacy code technique. The Driver knows the language, the project and so on, but the Navigator knows the techniques.
With new code Strong Style is very useful when you get stuck. And then the driver took control, pushes the rhythm and the steps to have progress.

Question (Michel): Do you explain to the people you use Strong Style?
Answer (Adi): Not really, because just coming up with theoretical concepts up-front feels weird. I just say “let’s pair and try this”. Maybe at the end of the session I might explain.
The other approach is a game called Farsight Navigator, where the Navigator looks far away for the design, and the Driver takes the small decisions. This technique works quite well, but you need to have very good Navigator skills to know where the design is going. So the role of the Navigator is to know which design options are not good and the solution would get stuck.
With Strong Style the Driver doesn’t need to know anything about the code, design, direction, etc.

Refactor but in small steps now TDD

TDD as if you Meant It: Refactor, but in Small Steps Now (Episode 14)

TDD as if you Meant It: Refactor, but in Small Steps Now (Episode 14)

About

After in the previous episode I took too bigger steps, during this episode I start all over and take smaller steps. The main differences are:

  • I’m not getting that far, but I have a stable point of stop, compared to the last episode when the last point of stop was resetting all the changes.
  • During the process I don’t feel so unclear, the points when I stop because I don’t know what to do are shorter
  • I feel flow, the next steps are obvious
  • While coding I am happier I know where I am going
  • For the next episode I know where I need to continue from.
Remote Pairing Michel

#RemotePairProgramming Ep 003: Strong Style Pairing with Michel Daviot

About

The third 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