Tag Archives: Programming

Talk: Easier to change CODE

Talk: Easier to change CODE

This is a talk from I T.A.K.E. Unconference 2016, Bucharest.

It is a hands-on talk, where I refactor some code live with the help of the audience.

Techniques

During this talk you will see techniques that are useful for tackling legacy code issues. You will be able to see how, with the help of the audience, the code can be improved to become easier to change. We want to change existing code in just a few situations: solve bug, add feature, improve the testability of the system. Remember that when you change existing code you understand what is the reason to do this.

Before changing the code is important to have some tests as a safety net. For that I am using Characterization Tests. Only after having these characterization tests, we can start to refactor the code, but with care in order not to introduce defects. Even though we have a safety net, it is not enough and bugs might appear. So to make sure we have more trust in tests the first refactoring steps are made with the purpose to be able to add unit tests.

Adding unit tests gives me better quality feedback, because if I introduce a defect I will know better what I have done wrong. A characterization test is too big, and I might need to dig a while to find the reason.

Changing legacy code needs to be done with care, in small steps and try to always remain with the tests on green. The longer I stay on red, the riskier is that I introduce defects and I lose my refactoring direction.

Easier to change CODE means the total opposite of the Legacy Code is Fear concept. I have my toolbox with legacy code techniques. I know how to use them,  and so I am able to make the code to be easier to change.

Video

 

Talk: Java User Group Łódź – Legacy Code is Fear

Talk: Legacy Code is Fear (Łódź, Poland)

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.

This is a talk from last year, before Global Day of Coderetreat Lodz.

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.

This talk is about how our unknowns make us feel frightened. We need to get passed that and learn techniques, practice them, understand how and when to use them. Only with more knowledge we will be able to tackle legacy code. But how do we acquire knowledge? We need to read, try, experiment, fail, and many more with some learning code base. Then we need do the same with production code. My advice is to never try these legacy code techniques on your legacy code base at work. You will be disappointed in the beginning because they will be difficult to apply. That is why it is important to start small, with an easier to understand code base in order to learn. And only after you can refactor that simpler code base, it is the time to start using the legacy code techniques on the bigger code base from work.

 

Here are the slides for the talk:

Talk: Wildcard Conference 2013 – Sherlock Holmes and Pairing

Even Sherlock Holmes was pairing. Are you? Let’s find some good practices in the talk below about Sherlock Holmes and Pairing!

During my work I am used to pair with my colleagues on basically anything. I do pair-programming when I develop software, we use pairing when we deliver trainings or when we write articles. I often do remote pair-programming with strangers. The most things I learned during the last years were by working in pair with someone I barely knew.
Pairing for me has the following main advantages:
– I learn a lot from my pair
– I extend my comfort zone and I collaborate better with anyone
– the product we work together is a lot better because four eyes are better than two

Please find examples from the activities of the well-known fictional character Sherlock Holmes on how his pair Dr. Watson helps him become better and finding the answer to their riddles.

 

 
And here are the slides for the talk Sherlock Holmes and Pairing

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:

Coderetreat: The toughest constraint

Coderetreat: The toughest constraint

Ask the attendees what they want

During the Global Day of Coderetreat 2014 (GDCR) I facilitated the event in Turku, Finland. That is when I presented the toughest constraint ever in any coderetreats I facilitated until now.

Since I have a lot of constraints in the list, some time ago I started to ask the attendees how difficult would they want the constraints to be. I am asking them on scale from 1 to 5, 1 being boring, and 5 being extremely difficult, what would they want to do as difficulty.

Another thing I’m doing, stealing the idea from Alex, is to ask the attendees of the coderetreat about the expectations they have. They write one expectation on a sticky note and we look at them and they choose what they want to practice. I tell them about constraints that will generate the kind of learning they want.

Usually during coderetreats the attendees want constraints of the difficulty between 2 and 3. Probably because 1 seems boring and 5 seems scary.

The constraint

Now it was different. They wanted the scary constraints. And they insisted. So here is the constraint.

universe-with-wormholes
Read More →

Legacy Coderetreat: Episode 1 – From Nothing to System Tests Codecast

From Nothing to System Tests – Codecast

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.

Codecast

Before starting to change any legacy system you need to know you will not introduce any defects when changing the code. So one way would be to stay on the safe side and start writing some automated tests. These tests can be Golden Master type of tests, they can be Characterization Tests, or anything else that might give you this certainty of correct changes in a later stage.

This is a code cast in Java where I start covering with tests a simple code base. Please read the explanation of this technique in the Part 2 – From Nothing to System Tests blog post. Have fun!

 

This session has some prerequisites:

  • Good knowledge of unit testing and test doubles, especially mocks, stubs and fakes.
  • Very good knowledge of the programming language you use. You often need to use some hacks that will allow you not to change the existing code and be able to test it.
  • Open mind to new, sometimes mind-blowing, techniques and concepts.

Further it is very important to have good knowledge about software design, especially techniques of decoupling the existing code. It would be a good thing that any attendee would know about the SOLID Principles and have basic knowledge about Design Patterns.

Legacy Coderetreat: Part 2 – From Nothing to System Tests

From Nothing to System Tests

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

Whenever I need to change an existing system I need a safety net. These system tests knit a coarse safety net, very good if you want to have the safety of changing code later without introducing defects.

This is the first thing I usually do when I start working with a system that:

  • does not have any automated tests
  • is totally unknown to me

This safety net will be used during the next phases when the code will be refactored and cleaned-up, before being modified. Now let’s see a bit about the concept of this session.

from-nothing-to-system-tests

From Nothing to System Tests

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 →

Pair-programming game: Silent Programming

Silent Programming

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:

  • Useful when you have talkative people in your team that do not agree or agree but do not write enough code for one task.
  • The code is not easy to read

Concept

The two programmers are not allowed to talk.
All the communication is made through code.
They are not allowed to use paper or write comments in the code or other files.

Silent Programming

Silent Programming

Read More →