Tag Archives: System

Evolutionary Design: Normalize Growth

Evolutionary Design: Normalize Growth

The Definitions

Evolutionary Design is the practice of creating the components and interactions of a system while it is evolving, on the basis of the client requirements and user needs.

Normalization refers to a process that makes something more normal or regular

Normalization may refer to more sophisticated adjustments where the intention is to bring the entire probability distributions of adjusted values into alignment from Wikipedia

Growth refers to a positive change in size, and/or maturation, often over a period of time from Wikipedia

 

The Moment

I am a big fan of gardening. Whenever I can, I take care of my plants and think about subjects like Evolutionary Design. One moment I was taking care of my young tomato plants: I needed to rip the small leaves that grow and just take the food away from the flowers and fruits. And it struck me: any gardener is doing Evolutionary Design.

pruning

Read More →

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: 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 12 – Extract class

Extract Class

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

When working with existing code we need to look at the responsibilities of existing classes. If one class is too big, we need to extract new classes from that initial class. A class too big means that it’s not respecting the Single Responsibility Principle.

Extract Class

Extract Class

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 →