Applying the DRY principle

Post previously published in Spanish Aplicación del principio DRY

I always keep in mind that in software development it is very important to keep each business concept in one place only. Code duplication is a problem that we should try to avoid or at least restrict and systematically remove when needed.

But, sometimes, we blindly follow the DRY principle, without having in mind that each decision has a cost.  In this post, I will expose some points that can help us decide when should we remove the duplicates or when should we live with them.

• We should differentiate between duplication of business concepts, rules, validations, flow, etc., and duplication at the implementation level (for example source code with little duplication). 
• The duplication of business concepts and business definition should be avoided as much as possible.
• Sometimes duplication at the code level can be a hint, meaning that there is an abstraction waiting to be discovered, an emergent behavior of the system or a pattern that is common in our application. It is important to minimize, but it is not a drama if there is "some" amount of duplication. But be very careful to not generate a premature abstraction. In my experience, premature abstractions are much worse than duplication.
• If you develop using TDD it is better to duplicate code to reach green, and, once in green and well covered by the tests, refactor to eliminate the duplicates.
• Depending on the language (C++, Python, Java...) there are some kinds of duplication that either have a high cost of elimination or that don't have an idiomatic solution. In these cases, we must eliminate duplication only 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 duplication 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 always comes with an important cost. We should always keep this in mind when evaluating whether we should eliminate duplication 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, it means that we have created a bad/wrong abstraction and that the maintaining cost will increase a lot.

In summary:

• It is important to not have duplication of business concepts (low-level duplication 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 improvements in the maintainability cost derived from removing the duplications.
• If readability is harmed by eliminating duplication, 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 if you can't eliminate/modify it once you detected that it is not the correct one, you are generating more complexity than the one generated by leaving a small duplication.

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

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

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

• Team and organization related:
• Teal Organizations Sandro Mancuso. How they are trying to be a teal organization at Codurance. Very interesting talk.
• The 5 dysfunctions of a team  Patrick Lencioni. A good summary of the book with the same name (here my Book Review).
• the Key to High Performing Teams at Google Matt Sakaguchi. Deep conversation about which are the key characteristics of a high performance team. This ideas come from direct observation of which google's teams are the best performancers
• Agile related:
• “Productivity” is Killing Us Adam Yuret. Great Lean explanation: Flow, WIP, optimization for utilization, optimization for flow, Slack, constrains... Very good talk.
• Focus (or Stop Starting, Start Finishing) Another inspiring talk from Henrik Kniberg with live demo of some of the agile concepts.
• Agile Uprising podcast: Interview with Martin Fowler Great episode to know about the history of agile movement, including XP and the first steps of the community.
• TEDxRainier - Joe Justice - WikiSpeed Great example of agile mindset. Very inspirational.
• Others/Unsorted:
• 3X with Kent Beck Explore, Expand, Extract. In this talk, Beck, explain the different phases for a business and the trade offs and solutions adequate for each phase. Very interesting concept.  Another delivery of a similar talk at https://www.youtube.com/watch?v=GTzXCdBVSSA
• Successful Go Program Design, 6 Years On Peter Bourgon Bourgon presents recommendations on patterns and best practices for developing successful, scalable, and sustainable code using Go.
• Shrinking Microservices to Functions microXchg 2017 - Adrian Cockcroft. Talking about the new game changer for the cloud native applications
• Traps and Cookies: A Mystery Package from Your Former Self Tanya Reilly. A great talk about how can we avoid to generate a mine field in our projects. :)

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 team… a 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/

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