Monday, May 29, 2017

Construction engineering is NOT a good metaphor for software

Metaphors are a great tool to explain other people complicated concepts. Often, they help us to drive interesting conversations and expand the boundaries of the knowledge we have by borrowing ideas from other fields.

In the Software industry, it seems like one of these metaphors is particularly strong, the one that tries to explain software as building houses. We even use it at our universities to introduce the topic to newcomers.

In my opinion, this metaphor is not only wrong but also very dangerous. Thinking about our profession as construction engineering makes us think that:
  • There is a clear construction phase separated from a maintenance phase.
  • Maintenance is cheaper and has a longer duration than the construction phase.
  • Once we have enough documentation and schemas, we can just follow the plan.
  • There is no incremental value. The construction goes from "not done" to "done".
Even if you think it might help in some way, please reconsider.

It does generate more problems and confusion than not using it at all.

In Software, features are done when the last customer stops using it. Maintenance is way more expensive than bootstrapping the project. There is no separation between construction and maintenance.

Software is Agile, Lean, it does change and evolve continuously. Software requires constant adaptation. Agile becoming mainstream in software projects is not a coincidence but the revelation on how Software works nowadays.

Software is not delivered in in CDs anymore. Systems are developed, grown and run as biological organisms evolving all the time.

It is true there are different phases within the roadmap of digital products and that there are different trade-offs to consider, but each of these phases are determined by evolutionary steps. Change is the only constant.

We can do better, we should strive for a better metaphor to help us being more effective explaining what do we do and how Software works.

Perhaps, a comparison with medicine might be more accurate

  • It is a knowledge-based profession
  • No one wants medicine or surgery if it can be avoided
  • Clean code is like eating healthy or making exercise
  • Pairing and code review is the second opinion
  • Making changes to the system running is like making surgery with the patient alive

Medicine might not be a great alternative but it's better than the original construction engineering proposition. Construction engineering will make us think the construction phase requires heavy investment when in reality the cost will always be in evolving the system.

Software is never done, it is always evolving. Software is not done until the last customer logs out and the servers are shut down.


  • Some projects have very well defined phases, and that's okey. Hopefully, we'll have less and less of these projects each year.
  • Many thanks to @keyvanakbary for his help with the English writing.

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:

Saturday, April 15, 2017

Socrates Canaries 2017, experience and notes

The past week I attended to my second Socrates Canaries (Software Craftsmanship and Testing Conference)... This posts summary the experience (things I have learned, ideas to explore, techniques to use...). The Socrates event is an open space, so whatever happens is the only thing that could have :)

Notes from the sessions:

Under the umbrella (elixir) @gemcfadyen

Interesting and very practical presentation about how to organize and structure elixir application using the umbrella concept (  You have all the advantages of the microservices and you remove some of the cons because you bundle the services together with explicit dependencies. Georgine used as example. She also commented for learning elixir.

Craft thinking @mashooq

(Book Craftsman by Richard-Sennett)
Very interesting reflections on the crafts in general and the craft in the development of software. The ideas come from the book Craftsman (Richard-Sennett) and the interpretations from Mashooq. Great insights and very interesting discussion.
Some random notes:

  • Craftsmanship. Human Impulse. The desire to do a job well for it's own sake.
  • We should always consider "How" and "Why" we make something... 
  • From "problem solving" to a combination of "problem finding + problem solving". Finding problems is also a skill to learn.
  • Motivation matters more than talent
  • We need imagination to learn. We also need fail (a very important note for mentors...)
  • Learn to apply the minimal force needed (in software we should compare this idea with the use of frameworks... ;) )

Show your architecture @borillo @eferro (myself)

Ricardo and myself proposed this session... the idea was to show several architectures/designs and to discuss about the tradeoffs and decissions that generated each architecture. We discussed three designs, one from @borillo, another one from kuba and another one from myself (@eferro).
We discussed and explain why we create this design and what was the tradeoffs... I hope that this session was interesting for someone :)

Building learning teams

A round table about how we can introduce a learning culture in a software development team or company. This are some random ideas:

  • Do food
  • Lean coffee (initially with a meta topic or about a shared interests)
  • Skill matrix
  • Know your company
  • Introducing learning time in work hours (with the possibility to extend after work hours). A good idea to this kind of learning is Lunch & Learn.
  • The company pay pluralshight or similar but remove the service is not used. You don't use it, you lost it.
  • Some reserved time: Give a tech talk, and as fallback, show a recorded talk and as a fallback a refactoring session or a mob programming session.

Personal productivity. @gardenunez

Another round table about how we can organize ourselves, as obsessive people, to be productive and not going mad in the process :)
Some tips about focus, pomodoro technique to deal with procrastination, making a list of the things that really matter, and so on...
And also some comments about not pushing to hard to ourselves... :)

Non Violent Communication Miguel Cruz

A good explanation about the how to have better relations and real connection using non violent communication. This kind of communication is a difficult skill that can be learned using the book Non Violent Communication book or going to a workshop or participating in some of the related communities (like the new created group in Barcelona).

The overall process consists in the following steps:
  1. make the observation (without judgement)
  2. express your feeling (it's difficult to separate feelings and opinions)
  3. express your needs
  4. making a request (in a concrete way). Is a request, not a demand, so it can be rejected.
The method is divided in three steps/levels:
  1. Self empathy
  2. Empathetic listening
  3. Be able to express in an empathetic way

I already read the book, but it requires practice. This skill can change deeply your relationships and life... so it is no easy, but deserves the effort :)

Serverless with AWS Lambda @mashooq (I acted as host)

This was a session hosted by me to ask Mashooq about codurance's experience using AWS Lambda in production. The session was divided in two parts, the first one was a presentation about this codurance's project and the second one was a discussion to identify if in my use case, have sense or no to consider using lambda.

Some lessons:
  • Bad choice for constant load
  • Force you to focus on business code (not in infrastructure)
  • Good base for security, scalability, performance
  • 1º understand the lowlevel stuff using aws api or/and aws cli, before using any framework or abstraction (apex, claudia.js, etc)... 
  • Prepare for runing localy from the day 0. Developing any mock/glue code needed. 
  • For web servers:
    • Latency problem to serving http request with JVM based languages. The startup/bootstrap process have a huge latency. They implement a periodic ping to avoid the stop of the containers, but this is not an elegant solution.
    • If you serve the frontend (js, html, css) from CDN, is difficult to synchronize with backend code. They need to invalidate the CDN resources and this cost money.
cost model - request based (pay by request)
strong infrastructure abstraction.

Another alternative for a web application using a JVM, than also have a strong infrastructure abstraction is Elastic Beanstalk

The second part of the session was a conversation about the possibility to use lambda for my use case, but for this part I will generate another post when I make the initial testing... In summary, seems that Lambda can fit our problem, but we should make the calculations about cost.

Taming the monolith  @mashooq

This session gave some ideas about how we can divide a monolith and how we should have in mind where are the vector of changes, because there is no best approach, it always depend of the nature of the change/evolution request that our system have.
Two powerful ideas:

  • Have in mind, at all levels, coupling and cohesion (for modular decomposition, to identify bounded contexts, to deine service limits, etc.)
  • Include the user journey

Some random quotes from this session:

  • "We need everybody to be architects" Mash
  • "Architecture. Design that is difficult to change" Mash

Liquid modernity @jordianguela

The goal of this session was to discuss about how this concept of "liquidity" is affecting us. This concept was coined by the philosopher  Zygmunt Bauman that talked about globalization, modernity and postmodernity, consumerism and morality.
The process was, we show different phrases from Zygmunt and we discusses the meaning and the pros and cons. And interesting session.
The concept of minimalism also appeared as one way to deal with this amount of changes  (Lifestyle Minimalism - Renouncing Your Busy Stupid Life)

Vuex + IDDD @nestorsalceda, @gualison (from the codingstones)

As I have no experience at all with front-end I only attended for the first part of the session. They described how they approach the architecture for a front end application using Vuex and the concepts of IDDD... You can see the results at:
They show the code and seems to be very simple and clean... a good stuff to research further.

PostgreSQL @juanignaciosl

A great presentation of the advances features of PostgreSQL... it seems to be the most powerfull DB... is the "Swiss army knife" of the databases... (relational, document oriented, pub/sub, with GIS extensions, rich data types...)
These are the slides of the presentation POSTGRESQL The one tool to bring to a desert island
Very instructive.

Other sessions, lightning talks and conversations:

  • Mental health
  • Different organizations (codesai) (book Reinventing Organizations)
  • How the codingstones distribute the profits (codingstones)
  • pointers in go
  • gendered language
  • carbon offset / climate change
  • Mob programming sessions
  • ...

Resource Corner

Related links:

Personal feelings and notes:

  • Somehow I improved my English so I interacted more and with more people :)
  • Old friend, new friends... I like this event... 
  • Great idea to come with the family and use the event as excuse to have family time at Canaries.
  • I returned home full of energy.
  • Great to have more developers from TheMotion attending this kind of conferences... The Socrates is  a great introduction to the Software Craftmanship community and to the unconference format. Thank you @gardenunez for coming to this event.
  • I love the open space format.

Thanks to the organizers, mainly @suuigd (Dani), @mangelviera (Miguel), the @CraftsmanshipGC community and to codesai.  
And of course to @eidrien for being the facilitator.

Sunday, April 02, 2017

Deadlines and commitments... the fallacy

There are two types of deadlines:
  • Fake deadline: arbitrary date that has no real meaning for the product, the team or the company. Very often it is used only to push a team because management believe that employees dislike work, are lazy, dislike responsibility and must be coerced to perform (Theory X. see McGregor's Theory X and Theory Y).
  • Real deadline: A date that can have lot of impact on the success of a product (for example because there are a presentation of other similar products, legislative changes, an opportunity to present the product in an event, a costly advertisement campaign, and so on...)
For me a fake deadline never works in the long term and its side effect is to destroy the capacity to improve the product or learn anything... With this kind of deadlines, the result is a team that dislikes work, dislikes responsibility and must be coerced to perform (a self-fulfilling prophecy of a theory X management)... A very bad team.

The real deadlines, are context that should can help the team to make decisions, and it is very important that the team knows this deadline, understands the importance and uses this information to delivery the best result possible for this deadlines. For sure, if the deadline is decided without the input from the development team or is not a deadline for all the people involved in the product, this deadline automatically becomes a fake deadline.

So remember, estimations are only educated guesses, but if someone requires a complete commitment, the team requires absolute control about all the variables and the plan...  And this makes no sense.

BTW: A product so easy to develop than you can design a perfect plan, is a product that shouldn't be created. No risk, No value.

More information:

Sunday, March 26, 2017

learning how to learn / Great course

"In a time of drastic change it is the learners who inherit the future" Eric Hoffer, Reflections on the Human Condition

Learning is the most important skill we can acquire to live a full and productive life in this complex, fast-paced, changing and interconnected world.
I found that the course "Learning how to learn" is a very good resource to improve our capacity for learning and to be more effective with the effort employed to learn.

The course has subtitles in different languages including Spanish, is very easy to follow and doesn't require too much effort or time.

The topics covered by the course are:
  • What is Learning?
  • Chunking
  • Procrastination and Memory
  • Renaissance Learning and Unlocking Your Potential

I truly enjoyed the lectures and the material and it helped me a lot to improve my efficiency learning new things... I also like how they introduce the "pomodoro technique" as a great tool to deal with  procrastination...

Thank to the authors, Dr. Barbara Oakley, Dr. Terrence Sejnowski and Becca Judd for this great resource...

So, enroll in the next edition Learning how to learn!!!!

Sunday, March 19, 2017

Book review: Team of Teams

Team of Teams: 

The Power of Small Groups in a Fragmented World 

General Stanley McChrystal, Tantum Collins, David Silverman, Chris Fussell 

A great book on how to generate a flexible and agile organization prepared to win in a complex world. The authors explain how they created a culture and an organization composed of a network of autonomous teams that at the same time have a shared purpose and a common context.
The most impressive thing about this book is that they described a real story of a deep transformation from a very difficult starting point:

  • A huge military task force 
  • A very solid command and control culture 
  • Several separated organizations 
  • Security risks about sharing information 

So no excuses… It can be done even in the most difficult contexts.

An indispensable book for anyone interested organizations that are adaptable, agile and prepared for this fast-paced, changing and interconnected world.

Note: An interesting podcast with one of the authors bosslevelpodcast interview McChrystal

The two pillars of agile software development

I like being agile and I can say without embarrassment that I have some experience in promoting this way of working and culture... From this experience I can say that what works in the long term is a way of working that put focuses on two things:

  • A healthy culture focused on people (collaboration, respect, team work, creativity...) 
  • Looking for quality and technical excellence (for example XP practices are a great starting point).

Too much focus on methodology without technical practices or without a lot of effort in the culture will probably end in a cargo cult agile and a failed change opportunity...

In summary, for me, from the three main points of agile (culture, methodology and practices), by default, I prefer culture and practices... A healthy culture shared among all the company, a minimal agile process and good technical practices, generate a good flow of outcomes with a sustainable pace...

By the way, this spirit fits very well with Extreme Programming (XP) and with Software craftsmanship.

Needless to say that with a good culture you can reach the rest of necessary ingredients, but it is necessary to have a clear vision of the destination and spend time and effort....

For sure, this is only my opinion and is only based on my experience, but, you know, this is my blog... :)

Sunday, March 12, 2017

interesting Talks/Podcasts (March)

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


Culture and leadership:

In spanish:

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

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

Sunday, January 29, 2017

Charlas interesantes sobre agilidad

Estas son algunas charlas relacionadas con la agilidad que he visto últimamente:
  • Aprender a distinguir el problema de las soluciones Carlos Blé. Completamente alineado con esta charla... interesantes pistas para pensar en el dominio del problema de forma que se mantengan abiertas gran cantidad de opciones para las soluciones. Complementaria a mi charla El arte del patadón pa'lante
  • Una historia sobre Clean Architecture con Ruby Dani Latorre Interesante charla siguiendo los principios de DDD y de Interaction Driven Design. Ejemplo de arquitectura limpia y sencilla de gran flexibilidad y que permite generar código muy sencillo de testear y evolucionar.
  • Priorizando productos con el modelo Kano Fernando Palomo. Ya conocia el modelo Kano, pero no he visto experiencias de aplicación y la verdad es que esta charla lo explica muy bien y da un ejemplo de como usarlo de forma muy sencilla y directa.
  • Alineando valores con prácticas técnicas Rubén Eguiluz, Alberto Pérez e Isidro López. Ejemplo práctico de como se puede unificar una cultura ágil fuerte con una búsqueda de la excelencia técnica mediate el uso de los principios y prácticas de XP. Como exmiembro de este equipo, esta charla me llena de orgullo y puedo confirmar que todo lo que se comenta es rigurosamente cierto :-)
  • Generando tests Rafael de Castro. Interesante charla que explica de forma muy sencilla la técnica de property based testing. Muy instructiva.
  • Comunidades de necesidad vs comunidades de soluciones Antonio de la Torre. Interesante charla sobre cultura agile en la que se superponen la curva de adopción, las comunidades de práctica y de soluciones e incluso el modelo Cynefin. Muy interesante. Basada en muchas de las ideas de Chris Matts

Wednesday, January 11, 2017

Book Review: Drive (Daniel H. Pink)


The Surpising truth about what motivate us

I think that this book is fundamental to understanding how “work” is changing and what motivates us in a knowledge-work environment.

The jobs from the industrial age are disappearing and each day the number of jobs that require a lot of knowledge and creativity are increasing. So the tools and structures created for the previous era have no sense anymore. In fact I think that some of these tools and ideas are counterproductive.

This book explains human motivation very well and how science is discovering and validating these ideas. It also explains the differences between these ideas and the ideas that are the basis for the actual management techniques used by the vast majority of the companies. It also describes some examples of successful companies that use a more modern approach based on these verified ideas.

An indispensable book to understand the human motivations discovered through science: Autonomy, Mastery and Purpose.

It also describes some companies that have been successfully adapted and that use this knowledge about motivation to be more successful.

Indispensable for anyone interested in human relations, world environment and in how to improve our organizations.

I am very pleased to see that a lot of companies in my environment (software development, IT, etc) understand these principles and use this knowledge to generate a more “rich” environment.

Book highly recommended

In case anyone prefers a very quick summary you may also find interesting the following TED talk of its author:

Saturday, January 07, 2017

Interesting talks I saw these days (work organization, complexity, leadership, product, trust, collaboration)

These are the most interesting talks I saw these last days: