Monday, February 27, 2017

Applying the DRY principle

Post previously published in Spanish Aplicación del principio DRY


I always have very clear that in software development is very important to have each business concept in one place only. On the other hand, is also true that the code duplicity is a problem that we should try to avoid or at least limit and remove systematically when needed.

But, sometimes, we follow the DRY principle blindly, without having in mind that each decision have a cost, so I will expose in this post some points that can help us to decide whenever we should remove the duplication or when we can live with it.
  • We should differentiate between duplication of business concepts, rules, validations, flow, etc and duplication at the implementation level (for example source code with small duplication). 
  • The duplicity of business concepts and definition should be avoided as much as possible.
  • Sometimes duplicity at the code level can be a tip saying that there is an abstraction waiting to be discovered, an emergent behavior of the system or a pattern common in our application. Is important to minimize, but it is not a drama if there is "some" amount of duplicity. But be aware that you should be very careful to not generate a premature abstraction. In my experience premature abstractions are much worse than duplicity.
  • If you develop using TDD is better to duplicate code to reach green, and once in green and well covered by the tests, refactor to eliminate the duplication.
  • Depending on the language (C++, python, java...) there are some kind of duplicity that have a high cost of elimination or don't have an idiomatic solution. In these cases we must eliminate duplicity when the result is easier to understand (not only for you, but for the whole team). In the face of doubt, readability must always prevail.
  • It is important to know that when we eliminate duplicity we usually create a common class, a library, a method or any other artifact that allows us to reference / use it from several parts of our code. This is a dependency between the client code and the code to be reused. Dependency is one of the strongest relationships between code and is always an important cost so you should have this in mind when evaluating whether we should eliminate duplicity or not.
  • We should always depend on artifacts that are more stable than ourselves, that is, if we extract common code to a library, but the API of this library changes all the time, this mean that we have created a bad/wrong abstraction and the maintaining cost will increase a lot.

In summary:

  • Is important not to have duplication for business concepts (low level duplicity is less important).
  • We should always evaluate the danger of creating a premature abstraction.
  • We should evaluate the trade offs between the cost of adding a new dependency vs the maintainability cost improvements derived from removing the duplication.
  • If readability is lost by eliminating duplicity, we are doing it wrong.
  • Is better to follow a process of use, use, reuse, and later create the abstraction (instead of directly creating the abstraction).

If you can't afford to wait before creating an abstraction or you can't eliminate/modify the abstraction once you detected that is not the correct one, your problem is that you are generating a great problem and worse complexity than the one generated by leaving a small duplicity.

Although the DRY principle may seem simple to understand, its application, as always in software development, is not simple or systematic.



Sunday, February 26, 2017

More interesting talks (teams, agile, others...)


From the talks I've seen lately, these are the most interesting.

Tuesday, February 21, 2017

Honey badger Team

One of the most impressive things about this last year is the great tech team generated at TheMotion. Another impressive thing is the platform, but it deserve another blog post...

When I arrived to TheMotion, I couldn’t say that the tech team had bad members, but the practices were not the best for the level of change and the scale required.

For example, some silos started to appear (front end, back end, video, etc), there was a tendency to generate feature branches that lived forever and the deployment and infrastructure was semi manual and without a good cadence for putting increments in production. For example, there were two environments, staging and production, and sometimes a feature could live in staging for more than a week before going to production.

Another “weird” practice was that the code was owned by only one developer, so there was some kind of “pipeline” for development for each feature that generate tons of integration work and coordination problems.

This was the starting line, but with some work, mentoring and sometimes being a little bit “radical” with the approach about agility, all of these practices and tech culture changed for the better.

From the beginning, the eagerness to learn and to make continuous improvements allows us to change our behaviour very deeply. You can have the fortune to work with very talented people, but if each one work individually and they are not aligned, the result can be worse than working with no so talented people that work as a team. So it was clear to me that the most important thing was to align all this talent to share a vision, practices and culture.

I think that having enough “mentoring power” for the size of the team is key. For example, I can myself teach some of the XP practices, but this is not enough when the team have ten members. To improve this, the collaboration of Modesto San Juan and Alfredo Casado from Carlos Ble y Asociados (now codesai) was key, because the message was clear and the impact of three persons focused on transmitting the practices was powerful enough to generate the change… It's always important to have critical mass and generate early adopters that helps to spread the change :-)



In parallel to introducing modern agile practices, there was another change going on… the generation of a high performance team. A team of people that trust each other, that want to learn together and that have no problems to have conflicts or propose different technical solutions… I can’t explain how we made this change, from a group to a team… I can only say that if you treat people as adults, try to help anyone and learn from others, the magic can happen. It is like being a gardener, you can plant flowers and take care of the environment (protecting the team, being an example of the change that you want, making the culture explicit, etc), nothing more, only water the garden.

In this case, the magic happened and the group growth to become a teama great development team, the Honey Badger team :-)



Right now, our practices include, continuous delivery (several times a day), TDD, simple design, immutable infrastructure, infrastructure as code, collective ownership and we work as a high performance team with our own identity and a high level of trust…. And this change only in 15 months…

Some of the actual Honey Badger team at https://www.themotion.com/about/

Saturday, February 18, 2017

Book Review. The five dysfunctions of a team

The Five dysfunctions of a Team

by Patrick Lencioni


This book helps to identify and solve the most common and important dysfunctions of a team. It helps to convert a group of related people working in an organization into a high performance team that works as a cohesive unit that can achieve much more than the individuals by themselves, or working as a group.


As an example, it uses one of the most important teams in any organization, C-level management. It examines the problems, possible solutions, as well as the process to make this change possible. The truth is that the tips, method and processes can be applied to any group of people who want to become a real team.


The first part of the book is written like a novel, very much like The Goal or The Phoenix project. The second part gives tools and describes the framework to create good teams.

Very instructive and easy to read book. Good for anyone interested in working or forming teams.

Discovered the illustrated version via Luis Artola :-)