Tag Archives: Software

Talk: Agile Lean Europe 2014 – Being a Community Bumble-Bee

During the last five years or so I have been travelling Europe and meeting a lot of people in local communities of practice. My main purpose is to teach the local groups and to learn from them. My purpose was and is to pollinate ideas from one community to the other. If more of us do this, our knowledge will grow richer and faster.

The main visible activity of the Agile Lean Europe community is the ALE Unconference that moves each year from city to city. But there are a lot of less visible activities, people meet each other and learn across the country or language borders.

During this talk I want to share my learnings with you about local communities and how rich those experiences can be.

 

Here are the slides for Being a Community Bumble-Bee

Acknowledgements

Many thanks to Thomas Sundberg for proofreading this post.

Talk: Agile Lean Europe 2014 – Legacy Code is Fear

Legacy code is fear because we fear the unknown. Learn what you need to learn in order to be less scared about legacy code during this talk.

You are a programmer. Someone from the company comes with an idea to add a feature and they are sure this new feature is very easy to add. And it should be. But the code is old. The code is a mess. Nobody in the firm knows any more that part of the system. You need to change that ugly piece of code. You are afraid that you might introduce defects. Legacy code is fear.

 

Here are the slides for the talk Legacy Code is Fear:

Legacy Coderetreat: Part 9 – Use Mocking Framework

Use Mocking Framework

Blog post series

This blog post is part of a series about legacy coderetreat and legacy code techniques you can apply during your work. Please click to see more sessions about legacy code.

Purpose

By using mocking frameworks we are writing short and easy to read tests. The duplication of test doubles written by hand is minimized by the use mocking framework.

mocking-framework

Read More →

Legacy Coderetreat: Part 8 – Extract and Override

Extract and Override

Blog post series

This blog post is part of a series about legacy coderetreat and legacy code techniques you can apply during your work. Please click to see more sessions about legacy code.

Purpose

Almost always when needing to test existing code we bump against dependencies that make the system untestable. This technique is useful to extract the static dependencies. After that we can use dependency inversion in order to be able to really test the systems.

With this technique we can transform untestable systems into testable systems, step by step. The steps are small because we want to enable safety while changing the code.

Extract and Override

Extract and Override

Read More →

Legacy Coderetreat: Part 7 – Dependency inversion

Dependency Inversion

Blog post series

This blog post is part of a series about legacy coderetreat and legacy code techniques you can apply during your work. Please click to see more sessions about legacy code.

Purpose

As you found out from the previous post, it would be a good idea to refactor in a safe way. This session is about another concept that will prepare for the tough refactorings ahead.

Dependency inversion is one way of transforming a tightly coupled system into a system that has a core and many small external dependencies. These external dependencies can be called also plugins.

Sierpinski_Racket_example Read More →

Legacy Coderetreat: Part 1 – Introduction

Legacy Coderetreat

Blog post series

This blog post is part of a series about legacy coderetreat and legacy code techniques you can apply during your work. Please click to see more sessions about legacy code.

A bit of history

On 26 November 2011 I had the honour of being an attendee at the second ever Legacy Coderetreat, which was supposed to be the first one in the world. But my friend Johan Martinsson from Grenoble beat Erik and me to it. Anyway I was part of the second ever Legacy Coderetreat in the world, facilitated by JB Rainsberger. JB had come with this concept of using the Coderetreat format, but for legacy code.

At the beginning of the day he presented us the problem, like in any other coderetreat. The problem was an ugly trivia game and you can find the sources here. At that time the code base was translated, from Java, only in a couple of other languages. Now you can find almost any language you want, thanks to the worldwide community of passionate developers who translated the code base.

JB facilitated the event like you could find in here, with a lot of details. But in short we would start with a free session, then follow with Golden Masters, continue with Subclass to Test, Replace Inheritance with Delegation and then Pure Functions. After each iteration we deleted the code like in any other coderetreat and swapped the pairs.

I liked a lot the fact that JB started this idea, because I am a big lover of working with legacy code. And this Legacy Coderetreat is such a good way to practice. But I had some other ideas on how to make it different.

legacy-coderetreat

Legacy Coderetreat

Read More →

A community event: Bring your own code

Bring your own code

Last month I started a new community event idea. It is called “Bring your own code”, and I “stole” it from what Antoine Vernois is doing in the Toulouse Software Craftsmanship Community. You can find here the event page. Tomorrow we will have the second edition that you can find here. Let’s go a bit into the mechanics of this event type.

Why

  • You have a project and you want a second opinion.
  • Your code needs improvements and you do not know where to start from.
  • You just like to show some awesome code and give it as an example.
Bring Your Own Code

Bring Your Own Code

Read More →

Pair-programming game: Solution Seeker

Solution Seeker

Blog post series

This blog post is part of a series about pair-programming games. To read about more please click see more sessions on pair-programming games. Solution Seeker is one of them.

Introduction

Start programming only when you have at least three solutions.

I heard about this concept when I started being a programmer. It made some sense then, and now it has even more sense. Especially for problems when we care about: scalability, performance, speed, security, etc.

Purposes:

  • You need to find a very good solution for a problem. But the “good” part here needs to be very well defined in advance. What do you seek for: security, speed, scalability, etc.
  • The domain of the problem might be known or not to you. If it is known, you just want to expand you knowledge and find lateral solutions.

Concept

The two pairs sit down at the table and are not allowed to write any code until:

  • they think about at least three possible ways of solving the problem
  • they note on paper or in a text file the solutions
  • every solution has a clear definition of how the goals (security, speed, etc.) are going to be measured in order to make sure the solution is right
  • the solutions are prioritized: the simplest and with best estimated results will be the first one
  • they start prototyping the first solution and measure its performance
  • only if the first solution does not fit the criteria, the second solution is prototyped
  • go on until one good solution is found.

This idea is extremely useful for finding solutions on hard problems or in areas like startups and research&development.

Solution Seeker

Solution Seeker

Read More →

Pair-programming game: Farsight Navigator

Farsight Navigator

Blog post series

This blog post is part of a series about pair-programming games. To read about more please click see more sessions on pair-programming games.

Purposes:

  • Make experienced navigators become better
  • Focus on long-term design decisions
  • Create design incrementally
  • Teach others how short-time design decisions can affect the design on the long term

Concept

Both the driver and the navigator need to know very clear which is the purpose, the destination, of their current code writing process. This concept works extremely well if you are doing Test Driven Development and you want to produce design incrementally.

The roles of the development are very well separated:

  • the driver is not allowed to think too much ahead
  • the navigator is not allowed to say anything about the implementation details unless some decisions would drive them out of their course.
  • in the case of conflict they need to stop and decide together which is the best approach

The driver

  • needs to focus only on the small implementation details.
  • will write code in small batches of maximum 5 minutes and will make sure the code is functioning well

The navigator

  • needs to see how the code will develop on the long run
  • if the driver tries to think too much ahead, the navigator needs to ask him questions until the driver understands why that decision is a bad one.
  • needs to be a very experienced person in programming and in software design
  • needs to keep their calm and explain always the objections to some path
Farsight Navigator

Farsight Navigator

Option
If you want to have an easier far-sight navigator session think to do a session of behavior slicing, value sampling and then order the resulting behaviors from simple to complicated. This activity will give you a first list of tests you need to implement. This list is just a temporary list, as some tests might be split, some new ones might appear or some of them might need to be discarded.

Outcomes

In the case of a problem where we cannot really know how to proceed we can apply this technique in production. If done well, we will have the simplest design possible, custom created for the problem we want to solve. We will write the minimum amount of code, but further we will minimize our possible design mistakes by focusing more on the design than usually.

This technique prevents us from doing mistakes that are hard to repair afterwards. You might say that you are doing TDD with special focus on long-term design decisions.

Whenever I used this technique, the efficiency of reaching a solution was astonishing from both the time spent and the quality of the solution point of views.

Remarks

This is the hardest pair-programming game I know. The purpose of this game is to make experienced navigators become better. I would recommend this only after at least 6 months to one year of continuous pairing from both of the pairs.

Have you read Dune by Frank Herbert? If you did not please read it because I guess you will like it. If you did read it, then you might remember the Spacing Guild and how they could guide the space ships by their special skills and protect them from danger. In the case of this game our navigator is like a Guild Navigator from Dune.

The navigator needs to  have special skills of pairing, programming, is extremely experienced in software design and is a very good communicator.

When will become a navigator with a far-sight?

Image credit: http://dictionaryproject.files.wordpress.com/2010/08/compass.jpg

Pair-programming game: Yes, and…

Yes, and…

Blog post series

This blog post is part of a series about pair-programming games. To read about more please click see more sessions on pair-programming games.

Purposes:

  • Make the team members that always disagree try to build up on top of the ideas already presented.
  • Some members of your team are very stubborn and you want to show them that there could be other solutions than their own.
  • You want to improve solutions immediately when you see a smaller or larger improvement option.
  • You want beginners to feel they add value when pairing with more experienced people.

Concept

When working in pairs none of the pairs is allowed to delete the code of the other person. We are looking for a common solution, that both of the pairs will agree.

Why? Often I see that the more experienced programmers drive and give their solution as the best one (and sometimes as the only one). But even if you are not experienced, either with the specific language or framework or generally, you might have some good ideas for making the current solution better. In order to work on that attitude you can do ping-pong pairing with the rules Yes, and…

So the rules are:

  • none of the pairs can delete the code of the other.
  • at each step when switching from driver to navigator one needs to improve the existing solution and tests.
  • whenever one of the pairs tries to delete the code, the other needs to say “You should improve the existing one. Please go back and say Yes, and… I will do…“.
  • none of the pairs are not allowed to be angry on this request of not deleting code.
  • only unused code can be deleted, like for example after refactoring the code is not used any more. Both of the pairs must agree that the code can be deleted.

Sessions on this topic should be short, around 30-60 minutes. The first sessions should be supervised by a coach who will make sure the rules are understood and well respected. These sessions might become tiring, so make sure you choose a period of the day when you do not have other hard things to tackle.

Yes, and

Yes, and

Read More →