Sunday, May 14, 2017

Interesting technical Talks/Podcasts (May 2017)

From the tech-related talks I've heard/seen lately, these are the most interesting:

Thursday, May 11, 2017

Focus on verbs, not on names

In my experience, a good strategy to understand deeply a system or a product is:
  • Focus the research and conversations on identifying behaviors (actions, verbs, business flows, and events).
  • For these behaviors, we should identify the dependencies, concurrency and parallelism requirements (what depends on what? what actions can happen at the same time? what actions don't depend on any other action? what are the sources/inputs for each action? etc).
Understanding the concurrent behaviors, allow us to design the system using small pieces that encapsulate state and communicate using messages. A good match for OOP, Actors, Microservices, etc.
Is easy to see that this strategy try to identify the interactions that the users have with our system and the corresponding actions (verbs). It does not focus on the entities used by the system (names).

However, the most used analysis strategy try to identify the entities first, losing all the context about the behavior (messages, flows, rules, etc). This strategy derives, not necessarily, but typically, on anemic and poor models. This is a common approach for people who have misunderstood OOP/OOA.


I value the process of identifying the entities (names) of a system, but I value more identifying the behaviors (verbs) that define how is used our system and what actions provide to the user.

We should remember that the customer DON'T want software/systems. The software is only a liability, not an asset. The asset is the actions provided to the customer.

Additional notes:

  • This strategy can be used at different levels... It helps us to identify bounded contexts, domain events, microservices... And at the low level can also help us to see the concurrent behaviors of each application or service. This allows us to design more reactive and concurrent systems.
  • Focusing on identifying names first, make very hard to fulfill concurrency, parallelism and scalability requirements. 
  • In the real world, things happen concurrently.
  • Event storming seems to be a good exercise to identify the domain events, the dependencies, and the behaviors.
  • Any strategy for the analysis should be used continuously. For me, development is always iterative, I don't see it any other way.

Sunday, April 23, 2017

Interesting Talks/Podcasts (April 2017)

From the talks I've heard / seen lately, these are the most interesting:

Interesting articles and blog post I read lately...

These are two interesting articles or blog post I read recently:

Thursday, April 20, 2017

Remove the excuses for not being a professional

Do you want to remove the excuses for not being a professional software developer?

  1. Release as frequently as possible, it will give you tons of feedback about the product, the design, the code, the architecture and so on... And at the same time, it forces you to have confidence in the code, automatic testing, automatic deployment, good tooling and infrastructure and learn one of the most difficult but useful skills for a developer... the skill of making large changes in small chunks  (parallel changes, dark releases, refactoring (code and data), etc...)
  2. Use TDD to put pressure on the design and force you to think about it and decouple from infrastructure.
  3. Pair as much as possible to be forced to have focus, understand other developers, think as hard as possible in the problem at hand. Or mob programming as an alternative. No twitter, no Facebook, no notifications... only respect and hard work. Professionalism :) 
  4. Be a whole team for the product, including of course the customer, business, and so on... Learn about the problem to solve, the business language, propose new features and experiments, find alternative solutions, even find better problems... Be part of the business and the product.

So when some people said that agile is a excuse to avoid being professional, I don't longer know whether to laugh or cry. If I want to be unprofessional, I prefer a classic/waterfall approach, without any delivery in several months :)

Learn about business, learn your craft, be part of a team with a purpose...
Be a professional software developer

And remember: nothings add value, until it helps real customers to make something...

References and related posts:

Sunday, April 16, 2017

Book Review: Nonviolent Communication: A Language of Life

Nonviolent Communication: A Language of Life

This great book explains how to have real and deep communication among humans. No matter how difficult the subject or how difficult the situation, this method proposed by the Dr. Marshall Rosenberg can improve our relations and communications by removing judgment from the equation and helping us to express our real needs.

This is one of the books that can significantly change your life… This form of communication is in our nature, but in most cases, due to our education (and upbringing), we have lost this skill, so the book is a method and a guide to recovering and developing it. Dr. Marshall guides us by using real examples and conversations from his workshops or from his experience as a mediator in difficult conflicts. He uses very clear language, it is not only very easy to read, but also very instructive.

For sure, this book is only the first step to discovering this skill and how deeply it can change your relationships. There are communities for practice, workshops and other books with more examples or exercises. Any skill requires practice.

In summary, a great book with a great purpose: to improve our lives, and relationships, express our real needs and help us understand the needs of others.

Related resources: