TDD as if you Meant It: Think – Red – Green – Refactor (Episode 1)

TDD as if you Meant It: Think – Red – Green – Refactor (Episode 1)

About

TDD as if you meant it is a very strict way of writing code in a Test Driven Development approach. One needs to follow the rules below:

Guidelines

In the first episode the main focus in to respect a few guidelines:

  1. Guideline 1: Always start with outputs when doing an analysis
  2. Guideline 2: Behavior Slicing
  3. Guideline 3: SIMPLIFY!
  4. Guideline 4: Introduce only one notion (domain concept) at a time, one per test
  5. Guideline 5: The rule of three “only extract duplication when spotted at least three times”
  6. Guideline 6: Triangulation

Read More →

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

 

Interview by Lemi Orhan for Software Craftsmanship Turkey

We discussed about things like:

  • Well crafted code
  • Ways to improve one’s craft
  • How to become a conference speaker
  • and many more…

Automated Tests Purposes

Automated tests: Why? How they help? Who needs them?

There are many types of automated tests out there. Let’s see the most used types of tests and understand how each one is useful.

Types of tests covered are:

  1. Unit Tests are isolated, focused on methods and classes. White box tests.
  2. Integration Tests are for checking how two different modules integrate. Black box tests.
  3. Integrated Tests are big, large tests showing how many modules integrate, with a business purpose. Black box tests.
  4. Acceptance Tests are showing that a features works well. Black box tests.
  5. Contract Tests are a special type of tests, that verify polymorphism integration of multiple components or classes.

Let’s take them one by one in detail.

Automated Tests System Under Test

Read More →

Hands-on Sessions: Performing Kata

Performing Kata

Blog Post Series

This is a series of blog posts about hands-on sessions you can facilitate at software conferences. You can find the rest of the hands-on sessions here.

Purpose

You can learn from someone who shows a live demonstration about a concept, technique or tool.

The idea of performing kata comes from martial arts. Its purpose is to teach a group how to tackle a specific problem in a systematic approach.

It is a very efficient way of conveying information because it is a mix of theory and practice.

Performing Kata

Read More →

Talk: Deliberate Practice at AgileWorks Bucharest

Talk: Deliberate Practice at AgileWorks Bucharest

Deliberate practice is a highly structured activity engaged in with the specific goal of improving performance. It is different from work, play and simple repetition of a task. It requires effort, it has no monetary reward, and it is not inherently enjoyable.

The common view held until recently was that expert-level performance was simply the result of talent and “natural abilities.” But scientists believe that expert-level performance is primarily the result of expert-level practice NOT due to innate talent.

So let’s have a discussion about how we can practice, formats and methods of practice in the Software Development world. I will touch technical type of practice (for programmers, testers, etc), and also organizational type of practice (managers, Scrum Masters, Team Leaders, Product Owners, etc)

Read More →

Call for Speakers I T.A.K.E. Unconference 2017

Call for Speakers I T.A.K.E. Unconference 2017

I T.A.K.E. Unconference

Code. Craft. Learn. Share. Repeat.

Software craftsmanship movement is raising the bar in tech industry. Are you also challenging the current practices, making experiments and trying new techniques?

Share your findings at the 5th edition of I T.A.K.E Unconference.

Call for Speakers is now open and waiting for practical, hands-on sessions, strong case studies, and personal experiences, delivered in an attractive manner.

Taking place in the tech rising city Bucharest, 11-12 May 2017, I T.A.K.E Unconference brings together 300 top-notch tech professionals, from 15 countries.

Simon Brown, James Lewis, Michael Feathers, Rebecca Wirfs-Brock, Tom Gilb, and Sandro Mancuso contributed to the previous editions as keynotes.

If joining, expect to meet software crafters, architects, DevOps, technical leaders and managers, startup CEOs, and CTOs.

Submit your proposal(s) here by December 5th!

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:

The Coderetreat Book

The Coderetreat Book

About

A couple of weeks ago I published the Coderetreat book together with Alex Bolboacă. The book is about how to facilitate and host a coderetreat event.

front-cover

Contents

It contains plenty of ideas and advice from both of us, based on our experiences of organizing, hosting and facilitating many coderetreats the least 7 years. The book contains specific advice on how to host and facilitate. Also a list of sessions is available in the book. Each session is documented in detail.

This is the first edition of the book, and we launched it now especially for the Global Day of Coderetreat (GDCR) 2016. We hope this book will help hosts and facilitators have wonderful events around the globe during GDCR.

Feedback wanted please

We plan to enhance the book with more chapters and more sessions. For now just enjoy the book and we hope we will receive plenty of feedback from you. We want the book to help you if you are organizing, hosting or facilitating a Coderetreat. Please tell us if it helped you, or how we could improve it for you. Thank you!