Author Archives: Adrian Bolboaca

Adrian was involved in developing software for domains like energy, ecommerce, banking, customs and ERP/CRM. He has been working with companies from Netherlands, Romania, Italy, France and Germany, and he is knowledgeable in software technical domains like: clean code, unit testing, test driven development, simple design, emergent design, working effectively with legacy code.

As a continuous learner and challenger of existing ideas and concepts, Adrian is a supporter of movements that give new ideas on how to continuously improve software and that embrace the values of software quality and efficiency. He facilitated many code retreats in Romania, Belgium, France, Germany, Netherlands, Finland, Bulgaria and has a keen interest in serious games and using gamestorming for continuous improvement.

He is fluent in Romanian, English and French, but when it comes to programming languages he supports language agnosticism, since he strongly believes that a programming language is only a tool towards higher level software concepts.

As a constant participant to conferences and workshops, he is recognized for challenging ideas and getting people out of their comfort zone, not out of disrespect or lack of reverence for his peers, but out of his desire to show people that there are always things to learn.

“I try to be a continuous learner and a continuous teacher, because I think good software comes from the skills of the people that are involved in the process, on each and every level. Whenever I write code I focus on reducing domain complexity to obtain maintainable software. I love to develop software that helps companies to improve their business, to implement solutions that improve their internal processes and to motivate teams to use their capabilities to yet another level.”

Adrian works as a technical and organizational trainer and coach at Mozaic Works.

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)

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

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:

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!

Programming by Wishful Thinking

Coderetreat: Programming by Wishful Thinking

Blog post series

This blog post is part of a series about coderetreat sessions.

Purpose

This session introduces the concept of top-down approach of Test Driven Development for a new feature.
By following the steps you will be able to understand how to add thin top-down features that you can show very fast to your customers. Many of the features will work, even though you will not have a fully functional system, just because you have used stubs or fakes for the parts of the system that are not yet implemented.

Programming by Wishful Thinking

Read More →

Legacy Coderetreat: Part 16 – Refactor Conditionals by Decomposing Conditional

Refactor conditionals by Decompose Conditional

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.

IF-THEN-ELSE-END_flowchart

Purpose

We often see code with conditionals that are hard to understand. The purpose of this technique is to make the code look readable by extracting a function with the condition. It will be easier to test the code if the condition is extracted and injected as a dependency.

This technique is useful when having good variable names is not enough to explain the condition. We can have some of the following reasons for wanting to extract a function with the condition:

  • The condition is duplicated in several parts of the class
  • The condition is duplicated along different classes
  • Test the condition in isolation, because of its complex nature
  • Test the code without understanding how the conditions work (inject conditions as stubs)

 

Read More →

Legacy Coderetreat: Part 15 – Refactor Conditionals by Explaining Variable

Refactor conditionals: Explain Variable

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. Refactor Conditionals - Explain Variable

Purpose

When you try to read a code base that has many conditionals, often the problem is that the condition itself is very hard to understand. This technique improves the conditionals by making them clear and very easy to read. Read More →

Legacy Coderetreat: Episode 13 – Document Possible Bugs with Tests – Code Cast

Document Possible Bugs with Tests – code cast

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.

Code Cast

This is a code cast in Java.

In the previous episodes we reach the moment when we extracted one simple class. We used the The Rule of Three and pure functions. This newly extracted class is covered with characterization tests. Then we wrote some unit tests in the following episode. But some of the behaviours seemed strange, and we thought they might be bugs.

Because we are never sure when working on existing code if some behaviour is a bug or a feature, we want to document all the suspicious cases. In order to do that, I am presentin three methods: use an annotation, prefix the test, use a diffent class.

Bug or feature? Check out the code cast to see all of them in action.

Read here more about this concept in my blog post.