Tag: TDD

Mars Rover – Refactoring Kata

On several occasions, I have used the Mars Rover challenge to train developers on the TDD principles. This time, I am using it as a refactoring Kata!

On my GitHub repository, I submitted the initial code that covers all the cases except the edge ones. But, the code I’ve written is in bad shape.

How to solve this Kata?

To solve this kata, you have two tasks to do. Firstly, you need to refactor the code and ensure it follows the clean code principles. Secondly, you need to write code that covers the edge cases for the Mars Rover.

Note: Before proceeding, make sure to fork the repository to your own Github account.

Task 1: Code Refactoring

  1. Start by writing unit tests to cover all the cases of this challenge. This is an important step to ensure that the refactoring doesn’t break your code. In total, you should write around 12 unit tests to have good coverage of the code.
  2. Now it’s time to refactor the existing code. While doing that:
    1. Think of the design patterns that might help improve the code
    2. Apply some of the S.O.L.I.D principles to have clean classes and methods

Task 2: Missing Features

There is a missing feature with my code. Currently, the rover can move out of the plateau if given the wrong commands. It’s your task to write the code that handles this case. The rover’s position should not be modified if the next spot is outside the plateau.

Finally…

This kata is relatively easy, but, I think it is a good first step into the world of code refactoring and writing tests for existing code.

Looking forward to your feedback…

References & Links

My takeaways from a TDD debate between Cope & Uncle Bob

As a developer, there is a high chance that you had a debate on the value of TDD in building software, especially if you apply it!

I had a lot of those debates!

A couple of months ago, I came across such a debate between Jim Coplien and Robert Martin (Uncle Bob). I found this discussion kind of interesting especially that it involves two leaders in software engineering.

You can watch the debate here:

Takeaways

Here are my takeaways from the discussion:

Three Rules of TDD

Uncle Bob defines the following three rules for applying TDD:

  1. Don’t write a line of production code without having a corresponding failing test
  2. Don’t write too many failing tests without writing production code
  3. Don’t write more production code than is sufficient to pass the currently failing test

Architecture is Important

Jim points out that he has no problem with those rules, his concerns are more architecture related. Jim and Uncle Bob would argue for more than ten minutes to finally reach an agreement on the importance of architecture. The below five points summarizes what they agreed on:

  1. Architecture is very important
  2. It is entirely wrong to assume that the code will assemble itself magically just by writing a lot of tests and doing quick iterations
  3. Design evolves with time and should be assembled one bit at a time
  4. An Object should have properties to give it meaning. At the beginning, those properties should be minimal.
  5. Architecture shouldn’t be created based on speculation

TDD and Professionalism

Probably the only disagreement you can sense from this debate is what defines a professional software engineer. For Uncle Bob, it is irresponsible for a software engineer to deliver a single line of code without writing a unit test for it. Jim, on the other hand, considers ‘Design by Contract’ to be more powerful than TDD.

My Point of View!

Personally, I have been applying TDD since I joined my team three years ago. After experiencing the benefits of this practice, we got to a point where we don’t write or refactor any line of code without having a corresponding unit test!

In addition to that, I had the chance to coach other developers by running coding dojo sessions at work.

All that makes me say that I agree more with Uncle Bob on the topic of professionalism!

References
  1. Coplien and Martin Debate TDD, CDD and Professionalism

Extreme Practices – Agile Tour Beirut

In my previous post, I shared with you how Philippe and I prepared for our talk “Extreme Practices.” In this post, I will be briefing the talk’s content; starting with the pitch and ending with the feedback! Philippe has already posted a blog on the talk that you can read here.

Pitching

dsc_0444-1

Each of the speakers had to brief their session in a thirty seconds pitch. This was mine:

This is unusual for me, because my co-presenter is in Paris! Philippe and I will demonstrate how we adopted the practices of Extreme Programming in our distributed team. We will also have two live demos; the first on remote pair programming and the second on remote meetings.

The talk

The audience started taking their seats; and in a couple of minutes, the room was full! We started by engaging the audience with three simple questions!

Who goes to work by car?

Who goes to work by bus?

Who goes to work on Skype?

Extreme programming

After introducing ourselves, our team and Murex, we spent the first half of the talk discussing four of the XP practices and their benefits.

  1. Ten Minutes Build
    • Helps developers stay focused on what they are doing
    • Shorten the feedback loop
    • Encourages developers to submit frequently thus resulting in easier bug analysis
  2. TDD
    • Only coding what makes tests pass decreases the possibility of generating bugs
    • In most cases, a failing unit test is enough to detect where the bug is and thus reducing the need for debugging
    • The refactoring step drives to clean code
    • Finding difficulty writing a test is an indication that refactoring is required
  3. Pair Programming
    • Benefits:
      • Newcomers tend to learn faster and submit on their first day
      • The quality of our code has increased
      • We didn’t notice any negative any impact on productivity
      • It helped us build a bonded team
    • Difficulties
      • It is very tiring for both the driver and navigator
      • It is risky because some developers prefer to work alone
  4. Retrospectives: For this part, we explained the five stages of our retrospectives
    • Check-in/energizer
    • Throwback
    • Collect insights & discuss
    • Actions
    • ROTI

Extreme programming in remote mode

Our second half of the talk was dedicated to sharing how we are applying XP in a remote mode, mainly focusing on Pair-Programing and Retrospectives. The discussion included the difficulties we faced at the beginning and how we managed to solve them. We ended the discussion on both topics by a live demo!

  1. Remote Pair Programming
    • To overcome the problem of time difference between the two cities, the pairs tend to share their calendars as well as an online document with the detailed tasks required to finish the story
    • The navigator might easily lose focus; that is why we try to submit frequently and switch control as much as possible
    • It is more tiring than local pair-programming especially if you have the headset on all day long. We agreed that anyone is free to ask for a break at any time
  2. Remote Retrospectives
    • The whiteBoards were located in Paris, and thus it was hard for us in Beirut to effectively contribute to the meetings. We managed to solve this problem by replacing our the whiteboard with an online Trello boards.
    • Initially, our meetings were held over the phone lacking any visualization of the team on the other side which caused a lot of frustration. To overcome this problem, our IT team installed Visio Conference rooms in both cities!

Here is a short video of the PairProgramming demo we did!

Main message

“You don’t have to move abroad for your dream job!“.

Remote work is becoming the trend! The advancement of the collaboration tools and technologies is making it easier for companies to adopt. In the future, you will see more and more developers working from home.

That was our message to the audience!  We concluded that there are three ways to organize your team when working remotely:

  1. Split the team in two if there are enough members in each city
  2. Work in open-source mode if team members are distributed over many cities
  3. Finally, adopt our remote XP practices if it is not possible to split the team in two

Feedback

Kudo.png

In addition to the above two Kudo cards, I received several positive verbal feedback at the end of the session. All that was a sign that our talk was successful!

Slides

Finally, you can have a look on our slides here:

 

Extreme Practices – The Preparation

Extreme Practices was the name of the talk Philippe and I gave at the AgileTour in Beirut on 15th of October, which based on the feedback was a successful one! Our main focus was on the practices of extreme programming and how to adopt them in a distributed team.

As this was my first talk, I decided to write two blog posts about it. In this first blog, I will be sharing the preparation whereas in the second post (in few days) I will be talking about the talk itself.

It all started with a discussion

Earlier this year, I attended a workshop organized by Pierre Hervouet who is also the organizer of AgileTourBeirut. After the session, we had a lengthy discussion on how we are applying Extreme Programming in our distributed team. We ended that conversation by agreeing that I give a talk at the AgileTour on that subject.

The next day I discussed with Philippe the possibility of him being my co-speaker. Unfortunately, visiting Beirut during that time wasn’t possible for Philippe! But later it struck us; why not giving the presentation in a remote mode (i.e. I will be in Beirut while he is in Paris) to simulate how we work on a daily basis.

That kicked off the preparation for the talk!

The content

After a couple of brainstorming sessions, we defined our presentation’s content and agreed that having live demos of remote pair programming and remote retrospective would make the talk more valuable!

Here is the content we agreed on:

  1. Introduction of ourselves and our team
  2. A short definition of XP
  3. A detailed explanation of some XP practices (below) and how we are applying them
    1. 10 minutes build
    2. TDD (Test Driven Development)
    3. Pair Programming
    4. Retrospectives
  4. A short story on how we started the distributed team
  5. Remote pair programming
    1. Explain how we are doing it
    2. Discuss the difficulties we faced and how we managed to solve them
    3. Do a live demo and solve parts of the FizzBuzz problem
  6. Remote retrospectives
    1. A couple of stories on how we initially started doing remote meetings
    2. Again, mention all the difficulties and the respective solution
    3. Do a live demo
  7. Final message
  8. Answer questions

The next step was building up the presentation slides and preparing the demos!

Slides design

We are both software developers. Thus we have limited design skills plus we usually are busy at work and can’t spend a lot of time on the design. That is why we requested the help of our Internal Communications team in the Paris office! The team focused on enhancing the slides’ background and images, but the content was not modified. After a couple of iterations with them, we ended up with very well designed and beautiful slides!

The below images show a sample of the difference!

Before
After

Presentation coach

I usually give talks, presentations and even training sessions at work, but this was my first attempt to give a talk at a conference. Yes, I was a bit worried about it! Thus, we asked for training with a professional coach from our training department in Paris.

We had two sessions with the trainer. The first one was in Paris (i.e. we were both in the same room) whereas the second one simulated the real scenario of the talk (i.e. I was in Beirut and Philippe in Paris).

The coach’s focus was on:

  1. The talk’s timing, to make sure that we don’t pass our allocated time. That led to the removal of some slides that were less relevance to the main message.
  2. The content, to make sure our message is well received by the audience. This led to the rewriting of parts of our text.
  3. Our presentation skills, which included how I stand on the stage, eye contact with the audience and Philippe’s intervention during the talk.

I have to say that this training was essential to the success of our talk! Some of the key points I learned from this training were:

  1. It is ok to forget and thus don’t hesitate to look at the notes if needed
  2. Limit the notes to headlines instead of full text
  3. Try not to look at the big screen
  4. Keep eye contact with all the audience

A big risk

Let’s admit, doing a remote presentation especially with an unstable connection as we have in Beirut is a huge risk! But we were well prepared!

Again here, I asked for help. But this time it was from the IT department at AUB (the tour’s host). They were very helpful, as they granted me a dedicated link with (relatively) high-speed Internet and performed two rehearsals to make sure everything is working as expected. (I took the below image from the last rehearsal)

To avoid any surprises during the talk, Philippe and I decided to record the two demos ahead of time and just play them if needed. Below you can check the two recorded demos.

Pair-programming recording

Retrospective recording

 

The preparation for the talk took a lot of time and was tiring, but it was worth as everything paid off at the end!

Stay tuned; next post is coming soon!

Coding dojo… One year later

Last week’s coding dojo session was a special one, not only because we brought a cake 🙂 but because it marked the first anniversary of those sessions at Murex Beirut. One year ago, I wrote a post sharing my experience on how we started this activity. Today, I am writing this post to share what has changed during this year.

Widening the scope

After twenty-eight sessions of practicing TDD, we decided it was time to adjust the scope a bit! Frequent attendees grasped TDD pretty well and suggested that we might benefit from those sessions to learn new technologies and practices.

After a brainstorming session, we agreed to label the session by one of four themes: Algorithms & TDD, New Languages, Kata & Workshops, and New Projects. We thought that by applying those themes we would increase the technical knowledge of all attendees, involve volunteers in the session preparation thus improving their presentations skills, and probably attract wider audience

Themes

Algorithms & TDD

Algorithms.png

We are all aligned that our primary purpose of this activity is practicing TDD, but in the case of complex algorithms using TDD is not always the optimal way (sudoku for example). Thus, we decided that in such cases we first would agree on the full algorithm then implement the code and write the sufficient tests to cover the different cases!

Lately, we’ve been using CodinGame to solve complex puzzles and algorithms, as the tests are already written, and they have an excellent graphical simulation of the puzzle execution.

New Languages

7Languages7Weeks

Learning new programming languages is one of the best approaches to improving someone’s programming skills; especially, when it includes learning different programming models (OO, functional, procedural, etc.) For those sessions, a volunteer learns the language alone and then presents it to the group in any form he/she prefers.

So far, we have learned two languages Scala and Ruby! For those sessions, we are using the book Seven Languages in Seven Weeks as our learning material reference and CodinGame as an exercising platform.

Kata & Workshops

JavaAgent.jpg

We defined kata as a presentation or short talk on a particular subject given by someone knowledgeable on that topic. A workshop, on the other hand, is a collaborative session where all take part of experimenting something new.

So far, we’ve had five of those sessions:

  1. A workshop on Git.
  2. Two kata sessions on machine learning.
  3. One presentation on Java agent and one on Android development.

Design patterns, development processes (Agile, lean, pair programming, etc.) and tools (docker, Gradle) are some of the candidates to be presented in next sessions.

New Projects

This is probably the hardest theme! The idea here is to implement an internal tool or app that can benefit other employees. Contributors to this theme will benefit from practicing TDD on a big scale project and learning new tools and technologies.

At this point, we are preparing a short list of proposals to get approval on one!  Hopefully, we can kickstart it soon 🙂

In Numbers

We initially started with thirty-four registered participants, but that number dropped to fourteen. Honestly, I think this isn’t a bad number!

The below graphs show the distribution of all the forty-seven sessions we’ve had so far. The graphs are grouped by theme and topic / language.

By Theme:

Number of Sessions per Theme
Percentage of Sessions per Theme

By Topic / Language:

Number of Sessions per Language or Topic
Percentage of Sessions per Language or Topic

More to Come

Thanks to the participants’ commitment and their eagerness to learn and improve their technical skills we celebrated the first anniversary of the coding dojo sessions. We will keep running those sessions, and we will keep improving them as we go! I hope that in one year from now, I will be posting another blog to share what we have done 🙂

Newcomers’ Training Program

Recently, I was in charge of training two fresh-graduate newcomers to our department. My mission was to prepare a two weeks program to ease the integration process with their teams.

After a short brainstorming, I decided to break the training into the following seven topics:

  1. Agile Practices: Their first assignment was getting acquainted with the Agile methodologies (mainly XP our working process). For that, I asked them to read a couple of chapters from two books “The Art of Agile Development” and “Extreme Programming Explained.”
  2. Dev Tools: Configuring some dev tools on their machines was the second step. This involved the installation and configuration of Java, IntelliJ, Maven and Perforce. Some of those tools such as Perforce and Maven were relatively new to them; so they took some time to learn more about it.
  3. TDD: By now, they were ready to write some code! And what would be better than following TDD to do that? Most of our teams started adopting TDD, thus coaching newcomers on TDD for simple dev problems is a must! For that purpose I picked the following two problems:
    • Mars Rover: This might be an easy problem, but I find it well suited to practice TDD especially for TDD newbies as it has a lot of cases to be covered by tests.
    • Coffee Machine: The beauty of this problem, is that it simulates what happens in the life cycle of an agile project, such as:
      • Defining new requirements at the start of each iteration
      • Writing the minimum code to implement the required features
      • Continuous code refactoring
      • Write the sufficient tests at each iteration
  4. Design Pattern and Code Refactoring: The two problems above may not be complex and can be solved in a short time, but the solution wasn’t the primary purpose rather it was introducing new concepts and practices to them. To make sure this purpose was achieved, I was performing multiple code review sessions during each iteration and suggesting enhancement at each time. This process elongated the time for each iteration, but it was worth. Some of the concepts I focused on were:
    • Test coverage
    • Builder pattern
    • Visitor pattern
    • Factory pattern
    • Bad and good code practices
    • Mocking
  5. Maven: They used Maven to build the code they wrote previously, but it was only maven’s basic commands. At this phase of the training, I asked them to dig deeper into maven to have a better understanding how it works; mainly focusing on:
    • Phases of build lifecycle
    • Dependency management
    • Plugins
    • Local and remote repositories
  6. SCM: Whether it is Git or Perforce, there are a couple of must know operations for any developer to be part of a development team. As a practice on those operations, they simulated a real dev cycle scenario by:
    • Sharing a common working directory on Perforce
    • Creating branches
    • Merging/Integrating changes
    • Resolving conflicts
  7. Continuous Integration (CI)As fresh graduates, the continuous integration was a new concept for them. Whereas for us, it is an essential process of our development cycle. It wasn’t possible to use an existing Jenkins instance to perform their testing; thus they executed the below steps:
    • Download and configure Jenkins locally on their machines
    • Submit their code to Perforce
    • Add a new job that syncs, compile code and execute the tests

 

I noticed the benefit of this training from the emails they sent me at the end of the program. They detailed what they learned and most importantly they were able to highlight the advantages of those practices and tools.

I hope you find this post helpful for your next newcomers’ training!