Category Archives: Talk

Talk: Behind Agile Practices (RO)

Talk: Behind Agile Practices (RO)

About

I gave this talk about Agile Practices at the Bucharest Agile Software Meetup Group, Agileworks. It’s in Romanian, because that’s what the audience wanted.

One by one I explain how some of the most common agile practices emerged. Also I explain when and why it’s a good idea to apply them. As seen in practice, some practices are just a hype, and they are very difficult to implement in an organization. Due to that you should always take into account the negative impact of introducing a new practice. Also be prepared for the consequences. There is no such thing as a perfect practice, you can always generate negative effects.

Agile started to become a hype because more and more companies are forced to deliver software faster. Because the markets are changing faster, the production and delivery speed is essential in this fast-paced world.

The last topic I am addressing is the apparent need or organizations to scale agile. There are multiple ways of scaling agile (horizontal, vertical, etc). Most of all we must ask ourselves if we really need to scale. Scaling agile too fast may generate counter-effects. Probably the worst effects are the decrease in productivity and minimizing the focus on the product value. Finally we can scale an organization and focus on the agile format, but not on its values.

Best Practices 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…

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 →

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 – 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:

Coding Games – video at xALEc

Coding games

This is a video from xALEc where I am part of a conversation about how one could teach programmers to be better by using games and pair-programming.