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.

Read More →

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

Read More →

Talk: Short Guide to your Agile Transformation

Talk: Short Guide to your Agile Transformation

About

This is a talk I delivered in Bucharest for the Agile Software Meetup Group. More and more companies want to transition to agile, because the benefits of faster delivery are essential in today’s software market.

Agile Transformation

Me and Mozaic Works’ approach to transforming an organization to agile has a lot to do with our core beliefs of small steps and fast feedback. For us an agile transformation is a tailored process for each organization, and the context is always essential.

Starting with the WHY is very important. I want to understand the internal values of the company and then decide together with the management, sponsors and the teams why they want to make this transformation. Without having the active involvement in any transformation, the whole process becomes very difficult or even impossible to put in place.

I don’t want to start from “what process to use” (Scrum, Kanban, DSDM, SAfE, etc), but rather discover the process while working with the people from that organization and understanding their needs. Together we create the process by applying things I know work well and by experimenting some things that might or might not work. As with any type of design, I prefer taking decisions as late as possible, because the more I learn the better the decision is.

Don’t commit unless you know why Chris Matts

 

Agile Transformation

Read More →

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.

Read More →

#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

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